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A dokumentum használata 


Mozgás a dokumentumban 


A dokumentumban való mozgáshoz a Windows és az Adobe Reader meg- 
szokott elemeit és módszereit használhatjuk. 

Minden lap tetején és alján egy navigációs sor található, itt a megfelelő 
hivatkozásra kattintva ugothatunk a használati útmutatóra, a tattalomjegy- 
zékte, valamint a tárgymutatóra. A 4 és a b nyilakkal az előző és a követ- 
kező oldalra léphetünk át, míg a Vissza mező az utoljára megnézett oldalra 
visz vissza bennünket. 


Pozícionálás a könyvjelzőablak segítségével 


A bal oldali könyvjelző ablakban tartalomjegyzékfa található, amelynek 
bejegyzéseire kattintva az adott fejezet/alfejezet első oldalára jutunk. Az 
aktuális pozíciónkat a tartalomjegyzékfában kiemelt bejegyzés mutatja. 


A tartalomjegyzék használata 


Ugrás megadott helyre a tartalomjegyzék segítségével 
Kattintsunk a tartalomjegyzék megfelelő pontjára, ezzel az adott fejezet 
első oldalára jutunk. 

Keresés a szövegben 


A dokumentumban való kereséshez használjuk megszokott módon a 
Szetkesztés menü Keresés parancsát. Az Adobe Reader az adott pozíció- 
tól kezdve ketes a szövegben. 
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Bevezetés 


A szoftvettechnológia területén az elmúlt tíz évben döntő mértékben 
meg-növekedett az objektumorientált fejlesztés súlya és jelentősége. Eb- 
ben a folyamatban fontos szerepük volt azoknak a tervezési módszerek- 
nek, programozási nyelveknek, ill. számítógépes segédeszközöknek, ame- 
lyek a tíz év során jöttek létre és terjedtek el. Ide sorolható az a kiemelke- 
dő eredmény is, amely az UML nyelv megalkotásában nyilvánult meg. 

Az UML (Unified Modeling Language, jelentése magyarul: Egységes 
modellező nyelv) három kiváló szakember, Grady Booch, Ivar Jacobson 
és James Rumbaugh egyesített munkájának a terméke. A szerzők a nyelv 
legelső, 1.0-s változatát 1997-ben adták közte az Egyesült Államokban. 
Azóta az UML az objektumorientált irányzat egyik modern, széles körben 
felhasznált alapvető eszköze lett. Elterjedését nagymértékben előmozdítot- 
ta, hogy grafikus elemeken alapszik, ami igen szemléletes és jól áttekinthe- 
tő alkalmazhatóságta vezetett. 

Az UML jelentőségét lényegesen növelte az a tény, hogy sikerült szab- 
ványosítani. Megalkotói szerint ,az UML egy általános célú vizuális mo- 
dellező nyelv, amely arra használható, hogy specifikáljuk, szemléltessük, 
megtervezzük és dokumentáljuk egy szoftvet rendszer architektúráját". Az 
iménti meghatározással összhangban a nyelv grafikus formában teszi lehe- 
tővé a szoftvet specifikálását, ill. működésének modellezését, aminek alap- 
ján a konktét implementálást el lehet végezni. A kiinduláskor előállított ún. 
tetvezési diagramok lényegesen különböznek az implementáláskor szöve- 
ges formában előállított programozási forráskódtól. A két megjelenési 
forma ugyanannak a szoftvernek a definiálására szolgál, viszont ez a funk- 
ció egymástól eltérő abszttakciós szinteken jut kifejezésre. 

A tetvezési folyamatban az UML-t a kiindulási fázisban használjuk, az- 
zal a céllal, hogy minél biztonságosabban, áttekinthetőbben és megbízha- 
tóbban készíthessük el a teljes szoftver tetvét, az objektumorientált fej- 
lesztési elvhez kapcsolódóan. Az így elkészült tervezési diagramok alapján 
válik lehetővé a forráskód megírása és a futtatható szoftver elkészítése. 
Ebben a folyamatban tetmészetes igény az, hogy az UML-fázis és a kódo- 
lási fázis teljes összhangban legyenek egymással. Mint ismetetes, az ilyen 
jellegű ekvivalencia igazolásának folyamatát szoftvetrverifikálásnak nevez- 
zük. 
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Mindezek után megállapítható, hogy az UML nem más, mint egy ter- 
vezési nyelv, ami egy szoftvet rendszet minél megalapozottabb kidolgozá- 
sának, elkészítésének folyamatát szolgálja. Ebben a tankönyvben bevezető 
áttekintést adunk az UML-ről, annak grafikus komponenseiről, az egyes 
komponenseknek az objektumorttentált fejlesztésben történő felhasználá- 
sáról, valamint a nyelvnek a tervezési folyamatban betöltött modellezési 
szerepéről. Mindezzel a szoftvettervezés átgondolt és konzisztens végre- 
hajtásának megalapozását kívánjuk elérni. 

A könyvben nem szenteltünk teret egyik meglevő programozási nyelv 
felhasználásának ismertetésére sem. Ehelyett olyan általános elveket tár- 
gyalunk, amelyek az implementációs nyelvek bármelyikénél alkalmazhatók. 
Az általános elvek megvalósítására azonban néhol bemutatunk egy-egy 
példát, elsősotban a Java nyelvre támaszkodva. 


A könyv tíz fejezetből áll, amelyek tartalma a következő: 


Az 1. fejezet az objektumorientált szoftverek legfőbb jellegzetességeit 
foglalja össze, a klasszikus procedurális szoftvetekkel történő összehason- 
lításban. 

A 2. fejezet bevezetést ad az UML nyelvről, majd itt kerül sot annak 
ismertetésére, hogy a grafikus tervezés és modellezés milyen kapcsolatban 
áll a forrásnyelvi megvalósítással. A további fejezettészekben egy olyan 
fejlesztési modellt mutatunk be, ami szervesen illeszkedik az UML-alapú 
tetvezéshez. Ebben a modellben a fejlesztési folyamat négy egymást köve- 
tő fázisra van felbontva. 

Az UML több különböző modellezési, folyamatleírási lehetőséget biíz- 
tosít. Mindegyik modellezési módhoz külön grafikus megjelenítési forma, 
diagramfajta tartozik. A nyelvi elemeket, ill. használatukat a könyv 3. feje- 
zetétől kezdve a 9. fejezetig terjedően mutatjuk be. Az egyes diagramfaj- 
ták, bemutatásuk sorrendjében a következők: 


e Use case diagram (használati eset diagramja): A szoftver tendszer kí- 
vülről látható működését írja le, a felhasználók és a tendszerfunkciók 
egymással való kapcsolatának ábrázolásával. (3. fejezet.) 

e  Osztálydiagram: Az egyes osztályok belső felépítésének és az osztá- 
lyok közötti statikus információs kapcsolatoknak a leírására szolgál. 
(4. fejezet.) 

e  Interakciós diagramok: Az egyes objektumok közötti együttműködést 
mutatják be, a köztük fennálló üzenetküldésekkel és azok hatásának 
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feltüntetésével együtt. Két fajtájuk létezik: a szekvenciadiagram (ese- 
ménykövetési diagram), ill. az együttműködési diagram. (5. fejezet.) 

e  Csomagdiagram: Az egymással szorosabb funkcionális kapcsolatban 
álló osztályok csoportba sorolására, valamint az egyes csoportok kö- 
zötti információs függőség leítására szolgál. (6. fejezet.) 

e Állapotdiagram: Egy adott objektum különböző állapotait ábrázolja, 
azoknak a vezérlési feltételeknek a megadásával, amelyek az állapotvál- 
tozásokat etedményezik. (7. fejezet.) 

e Aktivitási diagram: A vezétlési sttuktúrákat, valamint az egyes tevé- 
kenységek egymást követő, ill. egyidejű, páthuzamos lefolyását mutatja 
be. (8. fejezet.) 

e Komponensdiagram, valamint a telepítési diagram: Az előbbi a szoft- 
verkomponensek hierarchikus elrendezésének és a közöttük létesült 
kapcsolatoknak a leítására szolgál. Az utóbbi pedig azt ábrázolja, hogy 
egy szoftverrendszer komponensei milyen hatdveregységeken helyez- 
kednek el, és milyen kommunikációs kapcsolatok állnak fenn az egyes 
összetevők között. (9. fejezet.) 


A tankönyv 10. fejezete azokkal a problémákkal foglakozik, amelyek egy 
adott szoftvettetvhez tattozó különböző UML-diagramok egymással való 
összhangjára, konzisztenciájáta vonatkoznak. Ugyanitt lesz még szó a di- 
agtamok teljességének feltételeiről is. 

A fentiekhez még annyit fűzünk, hogy ezt a tankönyvet azoknak az 
egyetemi és főiskolai hallgatóknak ajánljuk, akik olyan informatikai kép- 
zésben részesülnek, amibe beletartozik a szoftverfejlesztés is. 


Budapest, Győr, 2006. május 15. 


A szetzők 
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1. Objektumorientált szoftverek 


ay 


1.1. A procedurális szoftverek jellemzői 


A klasszikus, hagyományos ún. procedurális elvű szoftvetek már fél évszá- 
zada vannak használatban, számos magas szintű prtogtamozási nyelv jött 
létre és terjedt el ebben a körben. Például: Algol, PL/1, Cobol, Fottran, 
Pascal, vagy a C. Ennek a tetületnek a modernebb ágát képviselik az ún. 
strukturált elvű szoftverek, amelyek jellemző nyelvei a Pascal és a C. 

A procedurális programoknál a kialakított adatsttuktúra szolgál atta, 
hogy a programegységek, ptogrammodulok információt cseréljenek egy- 
mással. Ezt a működési elvet az 1.1. ábrán szemléltetjük, ahol három mo- 
dul, M1, M2 és M3 vesz tészt a feladat megoldásában. A modulok rendel- 
keznek saját, ún. /okális adatokkal, ezen kívül egymás között pataméterek- 
kel is tudnak adatot váltani. 

A procedurális programozási nyelveken megítt modulok, a belső ve- 
zétlési feltételektől függően, egy-egy jól elkülönült utasítássorozat folya- 
matos végrehajtásán keresztül fejtik ki működésüket. Ebben a megközelí- 
tésben önálló modul lehet például egy Fottran-szubtutin, egy Pascal-pro- 
cedútra, vagy egy C-függvény. A modulok által használt adathalmazok fel- 
építésére nézve jellemző az azonos hosszúságú mezők ismétlődése, ill. a 
fix hosszúságú rekordok használata. 

Egy programrendszer működési folyamatait a különböző funkciókat 
megvalósító modulcsoportok együttese valósítja meg. A procedurális 
szoftvereknél a folyamatok és az adatok szét vannak választva. Ebből 
adódóan a funkciók megosztásán kívül még külön meg kell tetvezni az 
adatsttuktúrát is, mégpedig úgy, hogy az összhangban legyen a funkciók 
együttesével. Mint ismeretes, a megtetvezett adatsttuktúra összetétele, az 
adatok elrendezése igen nagy mértékben befolyásolja a számítási folyama- 
tok hatékonyságát. 

A legújabb alkalmazások már egyedi, speciális felépítésű adatbázist igé- 
nyelnek, amelynek szervesen kell igazodnia a feldolgozás jellegéhez. Ilyen 
alkalmazások, ill. adatbázisok a következők: 


e Számítógépes tervezőrendszerek (CAD: Computer-aided Desten): A mérnöki 
tervezési adatokat tartalmazzák, beleértve a tervezett komponenseket, a 
köztük levő kapcsolatokat, valamint a különböző tetvezési vetziókat. 
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e Számítógépes szoftvertechnológia (Computer-aided Software Engineering, CASE): 
A szoftverfejlesztők számára szolgáló adatokat foglalja magában, mint 
például a forráskódot, a modulok közötti függőségeket, a felhasznált 
változók definícióját, a fejlesztési folyamat menetét. 

e Multimédia: Képi, grafikus, térképészeti, hang, zenei, videó típusú in- 
formációt kódoló adatokat tartalmaz. 

e [rodaautomatizálási rendszerek: Dokumentumok tárolására, nyilvántattás- 
ára, kezelésére, keresésére, ill. munkafolyamatok adminisztrálására 
szolgáló adatok találhatók bennük. 

e Szakértői rendszerek: Nemcsak az adatokat, hanem az emberi szaktudást 
reprezentáló összefüggéseket, szabályokat is hotdozzák. 










































































M. Közös adatterület M 2 

Saját adatok Saját adatok 
Hívás 

Paraméterek Hívás 

Mg 

Paraméterek 
Hívás 

Saját adatok 











1.1. ábra. Procedurális modulok együttműködése 
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1.2. Az objektumorientált szoftverek jellemzői 


Az objektumorientált szoftverek, töviden 00-szofiverek tetvezési filozófiája, 
tetvezési elve lényegesen eltér a procedurális elvű szoftverekétől. Az OO- 
stratégia az információ elrejtésén alapul. Egy szoftver rendszert úgy kell 
tekintenünk, mint egymással kölcsönhatásban álló objektumokat, ame- 
lyeknek saját, privát állapotuk van, ahelyett, hogy egy közös globális álla- 
poton osztoznának. Ebben a megközelítésben a programkód és a hozzá 
tartozó adatok ugyanabban a szoftvetegységben találhatók. Ezek az egysé- 
gek maguk az objektumok. 

Az O00-technológia alapvető koncepciója az, hogy a feladatok végre- 
hajtása objektumok közötti ézemetek ksildése következtében történik meg. 
Az ilyen jellegű működés megköveteli, hogy az objektumokhoz definiálva 
legyenek azok az üzenetek, amelyekre azok reagálnak. 

Az O00-szoftvetek fontosabb jellemző vonásai a következők: 


e Az objektumok független egységek, amelyek önállóan működnek. 
Mindegyik objektum saját adatokkal rendelkezik, amelyek mindenkori 
aktuális értékei az objektum á/lapozát fejezik ki. 

e Egy objektum működése a benne meglevő önállóan kezelt, elkülönített 
utasításcsopottok, az ún. műveletek (angolul operations), vagy más néven 
metódusok (methods) végrehajtása révén valósul meg. 

e Az objektumok azáltal kommunikálnak egymással, hogy egymás műve- 
leteit, metódusait hívják meg, ahelyett, hogy változóértékeket osztaná- 
nak meg egymás között. Egy művelet hívása üzenetküldéssel történik 
meg. Az üzenetek ebben a szisztémában is hordozhatnak vezétlő pa- 
tamétereket. 

e Az objektumok által képviselt programok akár szekvenciálisan, akár 
párhuzamosan hajthatók végre. Párhuzamos végrehajtásnál az objek- 
tumok műveletei egyidejű, konkurrens módon mennek végbe. Ez egy- 
processzoros gépen nem jelent szó szerinti egyidejűséget, csak a vég- 
rehajtás szervezésében, ütemezésében jelentkezik. 


Az objektumok közötti együttműködés vázlatos sémáját az 1.2. ábrán lát- 
hatjuk. Itt az O1, 02 és 03 objektumok szerepelnek együtt. 

Az 00-kötnyezetben értelmezett üzenet nem jelent olyan fizikai jel- 
küldést, mint ami a számítógép-hálózatok csomópontjai (hosztjai) között 
megy végbe. Esetünkben egy üzenet nem más, mint objektumok között 
továbbított, valamilyen konkrét feladatmegoldásra vonatkozó kérés. 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 411b 


Az UML Nyelv használata Objektumorientált szoftverek 



















































































A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 12b 
Üzenet 
Paraméterek 
0, o, 
Műveletek (Metódusok) Műveletek (Metódusok) 
Saját adatok (Állapot) Saját adatok (Állapot) 
Üzenet 
Paraméterek 
O, 
3 
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1.2. ábra. Objektumok együttműködése 


Mivel egy objektum kizárólag üzeneteken keresztül tatt fenn kapcsolatot a 
külső környezetével, ezért lehetőség van arra, hogy módosítsuk az objek- 
tum változóit és metódusait, anélkül, hogy ez befolyásolná más objektu- 
mok működését. Ez a lehetőség, amellyel élve egy objektumot úgy tudunk 
módosítani, hogy az nem hat ki a tendszer többi tészére, az egyik legfon- 
tosabb előnye az OO fejlesztési elvnek, szemben a procedurális fejlesztési 
elvvel. Az OO-szoftverek létrehozásához számos jól bevált programozási 
nyelv áll rendelkezésre. Ilyenek például: Srnalltalk, C---t, Java, Perl, PHP. 
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2. Egy objektumorientált fejlesztési 
modell 


2.1. Az UML nyelv megjelenése 


Az objektumorientált elemzési és tervezési módszerek az 1980-as évek 
végén, ill. az 1990-es évek elején jelentek meg. Ennek a fejlődésnek egyik 
fontos későbbi állomása volt az UML nyelv kidolgozása. Az elnevezés az 
angol Unzfied Modeling Language (magyarul: Egységes modellező nyelv) kez- 
dőbetűiből származik. A nyelv három kiváló szoftvetfejlesztő, Grady 
Booch, James Rumbaugh és Ivar Jacobson együttes munkája révén jött 
létre, az Egyesült Államokban, 1997-ben. Ez volt az UML 1.0-s verziója. 
Azóta az UML az objektumorientált irányzat egyik modern, széles körben 
felhasznált alapvető eszköze lett. Elterjedését többek között annak kö- 
szönheti, hogy grafikus elemeken alapszik, ami igen szemléletes és jól átte- 
kinthető alkalmazhatóságra vezetett. Az 1.0 után a szerzők elkészültek egy 
újabb változattal, a 2.0-val, amit 2004-ben bocsátottak ki. 

A nyelv elterjedését nagyméttékben előmozdította az, hogy sot került a 
szabványosítására. A szabványosítási folyamatot az 00O-fejlesztés terüle- 
tén kulcsszerepet játszó OMG elnevezésű (Object Management Group) 
konzotcium hajtotta végre. Az OMG konzotcium a Hewlett-Packard, az 
IBM, valamint a Microsoft cégekből tevődik ki, mindegyikük az informa- 
tikai fejlesztések óriása az USA-ban. 

Megalkotói szetint ,az UML egy általános célú vizuális modellező 
nyelv, amely arra használható, hogy specifikáljuk, szemléltessük, megter- 
vezzük és dokumentáljuk egy szoftver tendszer atchitektúráját". Az iménti 
meghatározással összhangban a nyelv grafikus formában teszi lehetővé a 
szoftver specifikálását, ill. működésének modellezését, aminek alapján a 
konkrét implementálást el lehet végezni. A kiinduláskor előállított ún. zer- 
vezési diagramok lényegesen különböznek az implementáláskor szöveges 
formában előállított programozási fortáskódtól. A két megjelenési forma 
ugyanannak a szoftvetnek a definiálására szolgál, viszont ez a funkció 
egymástól eltérő abszttakciós szinteken jut kifejezésre. 

A tetvezési folyamatban az UML-t a kiindulási fázisban használjuk, az- 
zal a céllal, hogy minél biztonságosabban, áttekinthetőbben és megbízha- 
tóbban készíthessük el a teljes szoftver tetvét, az objektumorientált fej- 
lesztési elvhez kapcsolódóan. Az így elkészült tervezési diagramok alapján 
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válik lehetővé a forráskód megírása és a futtatható szoftver elkészítése, 
ami a fejlesztési folyamat végső célja. Ebben a folyamatban tetmészetes 
igény az, hogy az UML-fázis és a kódolási fázis teljes összhangban legyen 
egymással. Mint ismeretes, az ilyen jellegű ekvivalencia igazolásának fo- 
lyamatát szoftververifikálásnak nevezzük. 

Az UML atta szolgál, hogy vizuálisan specifikáljuk, megjelenítsük, ill. 
dokumentáljuk egy szoftverfejlesztés fázisainak eredményét. A nyelv igen 
hasznos a különböző tervezési alternatívák leírására, valamint az eredmé- 
nyek dokumentálására. Az UML-diagtamok egyaránt alkalmasak a megva- 
lósítandó objektumorttentált tendszer statikus és dinamikus megjelenítésére. 

A statikus képet adnak: az osztálydiagtam, a csomagdiagtam, a telepí- 
tési diagram, továbbá a komponensdiagram. Ezek az objektumortientált 
terv alkotó elemei között meglevő állandó kapcsolatokat dokumentálják. 

A dinamikus képet a use case diagram, az aktivitási diagram, az inter- 
akciós diagramok, valamint az állapotdiagtram szolgáltatják. Az ide sorolt 
diagramok a működésben, vagyis a progtamfutás közben megnyilvánuló 
változásokat, , mozgásokat" tükrözik. 

Az UML az 00-világban elterjedt Ada, Smalltalk, C-t, vagy a Java 
nyelvek bármelyikéhez felhasználható a megítandó progtamok tetvezésé- 
ben. Abban a tekintetben sem korlátoz bennünket, hogy milyen jellegű 
szoftver elkészítéséhez használjuk. Egyaránt alkalmazható valós idejű, 
webes, hálózati, vagy akár adatfeldolgozó rendszerekhez is. Jóllehet ez egy 
grafikus nyelv, de mégis ugyanúgy rendelkezik szintaktikai szabályokkal, 
mint a karakterekre épülő nyelvek. 

Önmagában véve az UML csak egy modellezési nyelv, semmilyen 
módszert, tetvezési megfontolás nem képezi integráns részét. Az idevonat- 
kozó tervezési módszerek ugyanakkor atra valók, hogy a nyelv felhaszná- 
lására adjanak irányelveket, megoldásokat, jól beváló , recepteket". Az 
ilyen jellegű módszerek harmonikusan összefüggő együttesét zzódszertannak 
vagy metodológiának nevezzük. Egyik ilyen fontos és széles körben elterjedt 
fejlesztési módszettan az, amelyet maguk a nyelvalkotók, Booch, Rum- 
baugh és Jacobson dolgoztak ki és alkalmaztak számos UML-projektben. 
A módszettan elnevezése: RUP (Rational Unified Process), atni a tervezési 
lépések szigorú rendbe foglalására irányul. 

Ennél a pontnál étdemes megemlíteni a következőket: A RUP elneve- 
zésben a hangsúly a , Unified Process7-en van, ami , Egységes folyamat"-ot 
jelent. A , Rational" előtag annak a cégnek a nevéből származik, amelyben 
a három alkotó dogozott a módszettan közös megalkotásakor. Ez a cég a 
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Rational, Inc. volt az USA-ban. A szoftvertechnológiában az UML-lel elért 
egyértelmű áttörés, és a cég által kifejlesztett Rational Rose elnevezésű 
CASE-eszköz piaci sikere után, 2003-ban az IBM felvásátolta a Rational, 
Inc.-et. Emiatt újabban már csak a Unified Process (UP) elnevezés kezdi 
jelölni a fejlesztési módszettant. A Unified Process jelenleg széles körben 
terjed a világon, a fejlesztési területek csaknem teljes spektrumát fedi le 
már. 


2.2. A tervezési modell és a programkód viszonya 


Egy szoftver rendszer terve és a tervet realizáló forráskód között, leg- 
alábbis elvben, szotos kapcsolatnak és konzisztenciának, összhangnak kell 
fennállnia. A terv, a kód és a kész tendszer közötti kapcsolatokat a 2.1. 
ábrán mutatjuk be. 

Az ábrán különbséget teszünk a fordítási időben és a futási időben 
megjelenő reprezentációk között. A forráskód, ami például Java, vagy 
Ct-t nyelven íródott, olyan dokumentum, ami egyértelműen definiálja a 
progtam működését. Azt a működést, amit a lefordítás, betöltés és elindí- 
tás előz meg. Az UML diagram is egy dokumentum, ami egy tendszert 
specifikál, de ebből a megjelenési formából még nem lehetséges közvetle- 
nül előállítani a forráskódot, mert nem létezik közöttük egy-egy értelmű 


megfelelés. 
/ specifikál 
UML: UML modell ] Objektum-struktúra 
absztrakt absztrakt 
nézetet ad nézetet ad 
j .  specifikál 
Programnyelv: Forráskód J Működő program 
Fordítási időben Futási időben 


2.1. ábra. A modell és a kód közötti kapcsolatok 
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A tetvezési diagramok és a forráskód egyaránt arra szolgálnak, hogy egy 
elvárt rendszert specifikáljanak, de abban különböznek egymástól, hogy 
ezt különböző absztrakciós szinteken fejezik ki. A forráskód a futtatható 
kód összes sajátságát kifejezi, hordozza, míg a tervezési modellből jórészt 
hiányzik a működésnek az a tészletessége, ami a kódban megtalálható. 

Az ábrán a vízszintes nyilak a közvetlen specifikációs kapcsolatot mu- 
tatják, míg a függőleges nyilak az absztrakciós kapcsolatot. 

Ebben a felfogásban az UML tetvezési modell a fottáskódban levő in- 
formáció absztrakciója. Mint ismeretes, az OO-progtamok működését 
maguk az objektumok valósítják meg. Ezek a futás közben létrejönnek, 
megszűnnek, miközben adatokat dolgoznak fel és kommunikálnak egy- 
mással. Az erre vonatkozó modellösszetevő az ábrán az objekíumsítruktára. 
Az objektumstruktúra annak az absztrakciója, hogy valójában mi történik 
akkor, amikor a progtam futásban, működésben van. 

A fentiekből két következtetés vonható le: 


e  Előszöt is az, hogy az UML nyelven megadott diagramok nem egysze- 
tűen csak képek, hanem konkrét jelentésük van a tekintetben, hogy mit 
specifikálnak a rendszer működési sajátságaita vonatkozóan. Ebben a 
megközelítésben a diagramok olyanok, mint a programok, csak azok- 
nál absztraktabb, elvontabb formában. 

e Másodszor, az UML nyelv jelöléstendszere jól követi azt a szemlélet- 
módot, amit a programozók alkalmaznak a kódírás folyamán. Ennek 
megfelelően, az UML és az 0OO-nyelvek ugyanazokkal a szemantikus 
alapokkal rendelkeznek, ami lehetővé teszi, hogy az UML-tervből kon- 
zisztens programfejlesztést lehessen megvalósítani. 


Az OO tetvezési nyelvek és programozási nyelvek közös vonása, hogy 
egyaránt a szoftverműködés meghatározására szolgálnak. Az ún. oljekíumn- 
modell az a közös számítási modell, amit az UML és az OO programozási 
nyelvek osztanak meg egymással. A kétféle nyelv között szoros kapcsolat 
van, ahol is a nyelvek különböző abszttrakciós szinteken fejeznek ki mű- 
ködési vonásokat a programokról. 

Az objektuammodell nem egy specifikus modell az UML-ben, hanem 
inkább általános gondolkodási mód az OO-programok struktúrájáról. 
Olyan koncepciók kerete, amelyek arra használhatók, hogy megmagyaráz- 
zák az összes tetvezési és programozási tevékenységet. Amint a neve is 
kifejezi, az objektummodell alapja azoknak az objektumoknak az együtte- 
se, amelyek a programot alkotják, amelyek a működését megvalósítják. 
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Ezekben testesülnek meg a számítógépi program alapvető vonásai, neve- 
zetesen a bennük levő adajok és azok feldolgozási folyamata. 

Egy adott objektum csak egy kis tészét valósítja meg a teljes rendszer 
funkcionalitásának. A rendszer általános működése a különböző objektu- 
mok közötti interakció révén valósul meg. Összegezve, az objektummodell 
a szoftverfejlesztésben azt fejezi ki, hogy úgy tekintjük az OO-programot 
mint egymással kommunikáló és együttműködő objektumok összességét. 

Az objektummodell az alapja az UML tervezési modellnek. Az UML- 
ben megvalósuló tervezési folyamat eredménye az egymással összekötte- 
tésben levő és egymással kommunikáló olyekíumok dinamikus hálózata. Ezen 
belül a szatkus modellek az objektumok között létező összeköttetéseket, 
dött üzeneteket írják le, valamint az üzenetek hatását az objektumokra. 
Mindezek az OO-ptrogramok futási, végrehajtási sajátságait is kifejezik. 
Mint látni fogjuk, a statikus és dinamikus modellt az UML ezekre a célok- 
ra szolgáló diagramjai valósítják meg. 


2.3. A fejlesztési folyamat általános menete 

2.3.1. A fejlesztési fázisok 

Az objektumorientált szoftverek fejlesztéséhez eltetjedten alkalmazzák azt 
a négy fázisra, négy fejlesztési szakaszta bontott modellt, amelyet a 2.2 
ábrán mutatunk be. A modell Booch, Rumbaugh és Jacobson munkájának 
az eredménye, az általuk kidolgozott RUP módszertan is ebből indul ki, és 


erre is épül. Az egyes fázisok, az eredeti angol elnevezésükkel együtt a 
következők: 


e . Flindítás (Inception). 
e — Kidolgozás (Elaboration). 
e — Megépítés (Construction). 
e. Átmenet (Transition). 














(Construction) 
(Inception) (Elaboration) Megépítés (Transition) 
Elindítás 1 — Kidolgozás 11213]..!n 1. Átmenet 


















































2.2. ábra. Az objektumorientált fejlesztés fázisai 
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Az ábrán látható teljes folyamat igen fontos jellegzetessége, hogy egytészt 
iteratív, tnástészt pedig egyúttal zz£rezentális 15. Mindez azt jelenti, hogy a 
szoftvett nem egyetlen kész adagban, egyszerre bocsátják ki a projekt vé- 
gén, hanem e helyett egymás után következő külön fejlesztési darabokban, 
fejlesztési változatokban. Ekkor az egyes darabok, változatok fejlesztésé- 
nek menete megismétlődik. Ezáltal a végső termék folytonos, több lépéses 
kidolgozású tészek egymás után megépülő változataiként jön létre. Ezek a 
motívumok elsősotban a zzegépítési fázisban érvényesülnek, ahol számos 
ismétlődő, itetatív lépés után áll elő a szoftver. Egy-egy ismétlés, itetáció 
itt magában foglalja az összes szokásos életciklus-tevékenységet, ideéttve 
az elemzést, tervezést, megvalósítást, valamint a tesztelést. A két motívum 
(iteráció és inktementáció) egyébként a folyamat másik három fázisában is 
érvényre jut. 

A végleges változat akkor jön létre, amikor már nincs szükség újabb 
ismétléses fejlesztés elvégzésére. Az inkrementalitás ebben a folyamatban 
úgy érvényesül, hogy mindegyik iterációban változik, vagyis módosul, bő- 
vül, esetleg szűkül a termék. (A folyamat hasonlít például ahhoz, ahogyan 
Lev Tolsztoj a , Hábotú és béke" című regényét ítta meg. A regényt az ító 
nyolc alkalommal fogalmazta újra, átdolgozva azt elejétől végéig, amíg a 
maga számára is elfogadhatónak nem találta. Mindez tizenkét évet igé- 
nyelt.) 

Az elindítási fázisban az egész projekt üzleti értelmét határozzuk meg, 
valamint hogy mire terjedjen ki a projekt, mit foglaljon magában. Mindeh- 
hez meg kell szerezni a projekt finanszírozójának a jóváhagyását, akinek el 
kell döntenie, hogy mekkora költséget tud vállalni. 

A kidolgozási fázisban már részletesebben meghatározzuk a követelmé- 
nyeket, magas hierarchikus szintű analízist és tervezést végzünk, azzal a 
céllal, hogy definiáljuk a szoftverarchitektúra alapjait, továbbá tervet ké- 
szítsünk a szegépítés fázisához. 

Az átmeneti fázisra olyan teendők matadnak, mint például a bétateszte- 
lés, a teljesítmény hangolása, vagy a felhasználók kiképzése. 

Még egyszer hangsúlyozzuk, hogy ebben a teljes folyamatban mind- 
egyik fázis zzeratív és inkrementáltis jellegű, több lépésre, ismétlésre és változ- 
tatásra, módosításra alapozva. Mindez különböző mértékben érvényesül 
az egyes fázisokban, mégpedig leginkább a zzegépítés során. 
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2.3.2. A RUP-modell két dimenziója 


Mint ismeretes, a szoftvetfejlesztési életciklust leító klasszikus vízesés- 
modell öt alapvető fázisból áll: 


Követelmények felállításának fázisa. 
Elemzési fázis. 

Tervezési fázis. 

Megvalósítási fázis. 

Tesztelési fázis. 


Sádő zzák odát ss 


Ez a modell egydimenziós, és egy fentről lefelé haladó tengelyen ábrázol- 
ható. Az egyes fázisok között, a menet közben felmerülő módosítási igé- 
nyek következtében, visszacsatolás jöhet létre. 

A RUP-modell magában foglalja a vízesésmodellt is, ezáltal kétdimen- 
zióssá válik. A két dimenzió oly módon jön létre, hogy a RUP négy fej- 
lesztési fázisa a vízesésmodell öt fázisával van kombinálva. Ez úgy érten- 
dó, hogy minden egyes fázis a vízesés-modell öt fázisa alatt képviselt z471- 
kafolyamatra (work flow) van felbontva (2.3. ábra). Másként fogalmazva: 
Mindegyik RUP fejlesztési fázisban öt egymást követő lépésben valósul 
meg a tetvezési etedmény. 


Elindítási Kidolgozási Megépítési Átmeneti 
fázis fázis fázis fázis 
Követelmények 
felállításának 
munkafolyamata 





Elemzési 
munkafolyamat 





Tervezési 
munkafolyamat 





Megvalósítási 
munkafolyamat 





Tesztelési 
munkafolyamat 

















2.3. ábra. A kétdimenziós RUP-modell 
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Az egyes fejlesztési szakaszok résztevékenységekte való bontása a teljes 
munkafeladat kisebb egységekre való szétválasztását teszi lehetővé. Mind- 
ehhez kapcsolódik az iteratív és inkrementatív végrehajtási folyamat, ami a 
szoftvetépítés egészét áttekinthetőbbé, hatékonyabbá és biztonságosabbá 
teszi. 

A RUP-modellről megállapítható, hogy igen jól szolgálja a nagybonyo- 
lultságú szoftverek létrehozását, mivel a feladat kisebb tészekre való bon- 
tását és a tészek összehangolt, lépésenkénti kidolgozását teszi lehetővé. 
Amit még hozzátehetünk: A szoftvetrtechnológia jelenlegi fejlettségi szint- 
jén, az objektumorientált szférában ez a modell alkalmazható a legelőnyö- 
sebben a többi más modellhez képest. 


2.3.3. Az egyes fázisok áttekintése 
Elindítás 
Többféle megvalósítása lehetséges, a projekt méretétől függően. Egy ki- 
sebb projekt elindítható akár egy rövidebb megbeszéléssel is. Például ezzel 
a felvetéssel kezdve: , Tegyük ki a szolgáltatásaink listáját a webre." Egy 
ilyen jellegű indításra elegendő lehet egy-két nap is. Ezzel szemben egy 
nagy projektnél elképzelhető, hogy egy részletes kivitelezhetőségi, megva- 
lósíthatósági tanulmány elkészítésére van szükség. Ez a tanulmány akár 
több hónapon keresztül is készülhet, több ember munkája révén. 

Az elindításnál igen fontos a projekt üzleti oldalának az alapos elemzé- 
se. Ekkor meghatározandó, hogy egyrészt mekkora költségvonzata van a 
projektnek, másrészt pedig hogy mekkora bevétel, ill. haszon várható be- 
lőle. A projekt métetének, költségeinek megállapításában döntő tényező a 
ráfotdítandó emberhónap, valamint az átfutási idő. Mindehhez járul még a 
felhasználandó hatdver és szoftvet eszközök költsége is. Az így meghatá- 
tozott költségeket, valamint az alapvető fejlesztési célokat részletesen 
egyeztetni kell a finanszítozóval. A finanszírozó egyaránt lehet az a cég, 
ahol a fejlesztés megvalósul, vagy pedig egy külső megbízó, amely meg- 
tendeli a fejlesztést a mnaga számára. 

Ebben a fázisban döntést lehet hozni arról is, hogy szükséges lesz-e 
megvizsgálni a projekt addigi menetét a következő, a kidolgozási fázisban, 
azzal a céllal, hogy módosítsanak a méretén, ill. a kitűzött célokon. 


Kidolgozás 


Az elindult projekt első teendői között át kell gondolni a követelményeket, 
jól meg kell érteni a problémát. Olyan kérdésekre kell választ adni, mint: 
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Mi a cél? Milyen jellegű szoftverre lesz szükség? Milyen legyen a specifiká- 
ciója, mit kell tudnia? Hogyan legyen az megvalósítva, hogyan fogjuk fel- 
építeni? Milyen szoftvertechnológiát alkalmazzunk? 

Ebben a fázisban szükség van a £orkázatok előzetes átgondolására, 
elemzésére. A lehetséges kockázatok ugyanis olyan veszélyeket rejtenek, 
amelyek nagymértékben félrevihetik a projektet, főleg időben és költsé- 
gekben, ami lehetőleg elkerülendő. 

Mattin Fowler, az , UML Distilled" című kiváló szakkönyvében (USA, 
1997) a kockázatok négy kategóriáját különbözteti meg: 


e Követelmények kockázata: A nagy veszély itt abban van, hogy olyan szoft- 
vert tűzünk ki célul, amely az elkészülte után nem fog megfelelni a fel- 
használónak, mert annak más lett volna a jó. A kidolgozás fázisában 
ette igen nagy gondot kell fordítani. 

e — Technológiai kockázatok: Az itt felmerülő lebetséges kérdések például a következők: 
—- Milyen OO fejlesztési tapasztalattal tendelkeznek a fejlesztők? 

—  Megoldható-e a feladat egy webkeresővel, ami egy adatbázishoz 
kapcsolódik? Jó lesz-e ehhez a C1-- nyelv? Vagy legyen a Java? 

e  Szaktudási kockázat: Itt a fő kérdés az, hogy megvan-e a kellő létszám 
és szaktudás a kitűzött feladat megoldásához? 

e  [/állalatpolitikai kockázat: Azt kell itt elemezni, hogy a fejlesztő cég, 
vállalat gazdaságpolitikájába beleillik-e projekt. Vannak-e komoly erők 
a cégnél, akik támogatják, vagy pedig ellenzik azt. 


Fowler szerint lehetnek még más egyéb kockázatok is, de azok nem min- 
dig jelentkeznek. Ezzel szemben a fenti négy csaknem minden esetben 
megvan. 

A kidolgozási fázis végső soton atta irányul, hogy a tendszer architektú- 
ráját hozzuk létre. Ez az architektúra az alábbiakból tevődik össze: 


e A követelmények részletes felsorolása. 

e A feladat kidolgozásának modellje, ami már a szoftvett alkotó legfon- 
tosabb OO-osztályokat is tartalmazza, felsorolva. 

e A megvalósítás szoftvertechnológiája, annak részei, és illeszkedésük 
egymáshoz. Például, egy webes fejlesztés kliens-szerver kapcsolódása, 
az interfészek megvalósítási módja, a felhasznált programozási nyel- 
vek, a fájlftotmátumok meghatározása stb. 

e Az igénybe veendő hatdver elemei, ill. a felhasználandó operációs 
tendszet. 
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Természetesen ez a fázis is egy iteratív folyamat, az architektúra is változá- 
sokon eshet át. A változások szempontjából nem mindegy, hogy melyik 
programozási nyelvet használjuk. Például a Java elbírja a jelentős architek- 
turális változtatásokat is. Ezt úgy kell érteni, hogy viszonylag kisebb plusz 
ráfotdítással lehet követni a módosításokat. Ezzel szemben a C-t nyelv 
már nehezen viseli el az átalakításokat, használata minél stabilabb architek- 
tútát tesz célszetűvé. 

Fowler megfigyelései szerint a kidolgozási fázis a teljes projekt mintegy 
2090-át viszi el időráfordításban. Ennél többet nem érdemes vele eltölteni. 
A véget étést a következő momentumok jelzik: 


e A fejlesztők már megnyugodtak afelől, hogy jól meg tudják becsülni az 
emberhónapos táfortdítást, a főbb részfunkciók megvalósítására szét- 
bontva. 

e "Mindegyik lényeges kockázat meg lett határozva, azonosítva, továbbá 
az is, hogy miként kell kezelni, leküzdeni ezeket a kockázatokat. 


Megépítés 

Ez a fázis tipikusan iterációk sorozatából áll, ahol mindegyik iterációs lé- 
pés valójában egy mini projekt. A szoftver főbb részfunkcióira egyenként 
el kell végezni az alábbi tevékenységeket: 


e elemzés, 
e tervezés, 
e kódolás, 

e tesztelés, 
e integrálás. 


Az ismétlések sora akkor zárul le, amikor egy demóvetzió adható át a fel- 
használónak. Ezzel egyidejűleg sor kerülhet a rendszer szintű tesztelés 
végrehajtására. 

A tesztelést és az integrálást nem szabad a fejlesztés végére hagyni. 
Minél később tesztelünk, annál nagyobb a veszélye annak, hogy sok hibát 
kell javítani a programokban, igen nagy ráfordítással. A késői tesztelés 
másik veszélye az, hogy ha a tesztek alapján módosítást kell végtehajtani a 
programon, az egy előrehaladott fejlesztésnél már költségesebb, mintha 
korábban oldottuk volna meg a módosításokat. Egyébként általánosan is 
igaz minden fejlesztésre, hogy minél később derül ki valamilyen tévedés 
vagy hiba, annál nehezebb a változtatást vagy javítást végrehajtani. 
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Fowlet azt az elvet vallja, hogy a jó tesztelés megköveteli, hogy nagyjá- 
ból ugyanannyi tesztkódot írjunk, mint amennyi programkódot magában a 
tetmékben. Ez az ökölszabály összhangban van azzal az általánosan elter- 
jedt tapasztalattal, miszerint a tesztelés a fejlesztési folyamatban mintegy 
5090-os arányban részesül. 

Ennek a munkának a kódítással együtt kellene folynia. Mihelyt készen 
van a kód, elkészítendő a tesztprogramja is. Mát a kódolás közben érde- 
mes azon gondolkodni, hogy miként, milyen módon is fogjuk tesztelni az 
adott programunkat. 

A tészegységek, modulok tesztelését Fowler szerint maga a fejlesztő 
végezze, csakúgy, mint az integrációs tesztelést is. Ezzel szemben a teljes 
rendszer tesztelése már egy független, különálló team feladata kell legyen. 
Olyan teamé, amely kizárólag tesztelésre van szakosodva. Az ilyen mun- 
kában tészt vevők számára az a siker, ha minél több hibát tudnak felfe- 
dezni, ami a szoftvetminőség szempontjából mindenképpen kívánatos 
hozzáállás. 

Mindehhez még annyit fűzünk, hogy az iteratív szakaszoknál is be kell 
tartani a részfeladatok teljesítésére megszabott határidőt. Ha ez nem sike- 
tülne valamilyen oknál fogva, akkor újra kell egyeztetni a projekt menetét, 
a finanszítozót is bevonva. 


Átmenet 


Ez az utolsó fázis. Az a lényeges jellemzője, hogy itt már nem történik 
valódi, érdemi fejlesztés. A szoftver funkcionalitásán nem változtatunk 
már, és hibakeresés sem folyik ebben a fázisban. Ezek a tevékenységek 
lezárultak az előző fejlesztési lépcsőkben. Itt azokat a végső simításokat, 
javításokat, módosításokat hajtjuk végte, amelyek a szoftvet optimálisabb 
működését eredményezik. Ez az optimalizálás a hatékonyabb, gyorsabb 
működés elősegítését szolgálja, másrészt pedig a felhasználói kényelem 
növelését. 

Az átmeneti szakasz tehát arra irányul, hogy a nyets végtetmékből egy 
optimalizált, , kicsiszolt?" végtermék váljék. Tipikus példa lehet erre az az 
időszak, ami a béta kibocsátási vetzió és a végső kibocsátási termék megje- 
lenése között telik el. 
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2.4. A fejlesztés végigvitele 
2.4.1. Kommunikációs problémák 


A szoftverfejlesztésben az a legnagyobb kihívás, hogy egy jól működő 
tendszett hozzunk létre, olyat, ami kielégíti a felhasználói követelménye- 
ket, éspedig ésszerű költségekkel megvalósítva. Ez egy valódi mérnöki 
feladat. 

A feladat megoldását tovább nehezíti az, hogy a fejlesztők szóhaszná- 
lata, zsartgonja sok esetben lényegesen különbözik a felhasználók zsargon- 
jától. Egy kórházi tendszer fejlesztésénél például meg kell küzdeni az or- 
vosi kifejezésekkel, amik ráadásul még csak nem is magyarul vagy angolul 
vannak. Ugyanilyen gondokkal járhat egy vasúti vezérléseket végző be- 
ágyazott szoftver elkészítése is, amihez a vasutasok szakkifejezéseit kell 
megétteni. 

A feladat pontos megéttése és a félreértésektől mentes kommunikáció 
kulcsfontosságú a kifejlesztendő szoftvert elfogadhatósága, minősége 
szempontjából. Ehhez annak a célnak az elérése kapcsolódik, hogy minél 
jobb, tökéletesebb specifikáció készüljön el, hiszen a specifikáción múlik 
az egész fejlesztés végeredménye. A tévedések csökkentésére az UML-ben 
egy alapvető fontosságú segédeszköz áll rendelkezésre: Ez a segédeszköz a 
use case, magyarul használati eset. (A tankönyvben általában megmaradunk az 
angol elnevezés használata mellett, mivel ez az elterjedtebb, és emellett 
könnyebb a kiejtése is.) 

Hgy-egy use case nem más, mint a rendszer kívülről látható viselkedé- 
sének a leírása, definiálása. Ebben a megjelenítésben fel van tüntetve a 
felhasználó, valamint a számítógépes rendszernek azok az összetevői, 
amelyekkel a felhasználó együttműködésben, interakcióban van. Ez a kép 
felfogható úgy is, mint egy pillanatfelvétel a működés közben. Egy szoft- 
vernek számos use case-e létezhet, attól függően, hogy milyen feladatokat, 
funkciókat lát el. A használati esetek összessége egy olyan külső képet ad a 
rendszerről, ami lehetővé teszi a teljes működés áttekintését a felhasználó 
oldaláról. Ugyanakkor mindez fontos támasz a fejlesztő számára is, aki 
ezáltal biztosabban megérti, hogy mit kíván a felhasználó. 

A use case-ek központi szerepet játszanak az UML nyelv alkalmazása 
során. Nemcsak a megértést segítik elő, hanem hasznos eszköznek bizo- 
nyulnak a projekt-tetvezésben is, mivel ezekre lehet alapozni az itetatív 
fejlesztést. Ez azt jelenti, hogy a felhasználóhoz való visszacsatolásban és 
az ismétlődő módosításokban is fontos szerepük van, lehet rájuk támasz- 
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kodni. Mindemellett nem csak a felszínen történő kommunikációhoz ad- 
nak segítséget, hanem a belső, mélyebb fejlesztési folyamatokhoz is, ami- 
vel a tankönyv későbbi részeiben foglalkozunk. 

A használati esetek nem hordoznak információt a megvalósítás módjá- 
ról, a rendszer struktúrájáról. A use case-eken alapuló megjelenítés végül is 
arra alkalmas, hogy a fejlesztőn kívül egyaránt el tudjon tajta igazodni a 
megrendelő, a felhasználó, a tesztelő, és egyáltalán mindazok, akik nem 
rendelkeznek ismeretekkel a szoftver konkrét felépítéséről, implementá- 
ciójáról. 

2.4.2. A kidolgozási fázis kockázatai 


Ebben az alpontban részletesebben áttekintjük azokat a kockázatokat, 
amelyek a kidolgozási fázisban jelentkezhetnek. (Ezekről szó esett már 
korábban, az 1.2.2. alpontban.) 


Követelmények kockázata 


Ennek a kockázatnak a csökkentésében sokat tud segíteni az UML hasz- 
nálata. Itt elsősorban a use case-ekre tudunk hagyatkozni, amelyek a teljes 
fejlesztési folyamat támaszai is egyben. 

A use case-ek különböző terjedelműek, különböző bonyolultságúak 
lehetnek. A fő dolog az, hogy mindegyik egy funkciót jelöl ki, amit a fel- 
használó is át tud látni, meg tud érteni, ami fontos is a számára. Ez a fajta 
segédeszköz hatékonyabbá és eredményesebbé teszi a finanszírozó és a 
fejlesztő közötti kommunikációt. 

A kidolgozási fázisban meg kell találni az összes olyan use case-t, ami- 
te a rendszer épülni fog. A gyakorlatban az nem lehetséges, hogy mind- 
egyiket elő tudjuk itt állítani, de a legfontosabbakat, és az összes fontosat 
viszont meg kell találni. Ehhez arra van szükség, hogy interjúkat ütemez- 
zünk be a felhasználóval, azzal a céllal, hogy use case-eket gyűjtsünk, 
amikhez szöveges kiegészítéseket is készítünk. Ezek nem kell, hogy túl 
részletesek legyenek, néhány bekezdésből álló rövid leírás elegendő hozzá- 
juk. A szöveg a lényeget tartalmazó legyen, olyan, ami alkalmas arra, hogy 
a felhasználó egyértelműen meg tudja étteni, és láthassa belőle az alapel- 
képzelést. 

Az UML kidolgozói által javasolt módszertan nem azt igényli, hogy a 
teljes rendszett egy ütemben alakítsuk ki. Fontos, hogy meglegyenek a 
kulcsfontosságú szoftverosztályaink és use case-eink. A tendszett ezekre 
fogjuk alapozni, és további kibővítéseket tudunk majd hozzájuk építeni. A 
bővítések újabb use case-ek létrehozásával járnak (inkrementális fejlesz- 
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tés), és ezek mind részei lesznek az iteratív folyamatnak is. A rendszer 
tehát lépésenként bővül, esetleges visszalépésekkel, javításokkal, módosítá- 
sokkal együtt. 

A use case-eken kívül itt jól felhasználhatók az UML más eszközei, 
nevezetesen az osztálydiagramok (class diagram), az aktivitási diagramok (activity 
diagram), a szekvenciadiagramok (seguence diagram), valamint az állapotdiagramok 
(state diagram). Ezek mindegyike a tervezési modell létrehozását szolgálja, 
miközben szotos kapcsolatban állnak a use case-ekkel és egymással is. 
(Ezekkel a könyv későbbi fejezeteiben részletesen fogunk foglalkozni.) 

A diagramokat egy külön erre a célra létrehozott modelltetvező team 
dolgozza ki. A team javasolt létszáma 2-4 fő. Annak érdekében, hogy ne 
tudjanak elveszni a részletekben, szoros határidőt kell nekik szabni. 


Technológiai kockázatok 


A technológiai kockázatok csökkentése érdekében ún. brozofíbust érdemes 
készíteni. A prototípus ebben az esetben egy megvalósított kísérleti prog- 
tam, amely egy részfeladat megoldásának kipróbálására alkalmas. Ezzel azt 
lehet vizsgálni, elemezni, hogy egy kisebb szoftverrészlet milyen működést 
mutat. 

Szemléltető példaként vegyünk egy olyan fejlesztést, amiben a C-T--t 
nyelvet szándékozzuk használni, egy telációs adatbázishoz kapcsolódva. A 
prototípus elkészítése a következő lépésekből állhat: 


e Vesszük a Ctt kompáljlert és a hozzá tartozó fejlesztési segédeszkö- 
zöket (7o0/-oka7). 

e A meglevő szoftvetmodell (tervezési modell valamelyik kiválasztott 
egyszerűbb részét leprogramozzuk. Eközben azt is nézzük, hogy mi- 
ként tudunk boldogulni a felhasznált segédeszközökkel, azok hogyan 
funkcionálnak. 

e Építsük fel az adatbázist, és kössük azt össze a C-- kóddal. 

e Próbáljunk ki több különböző segédeszközt. Tapasztaljuk ki, hogy 
melyikkel a kényelmesebb, hatékonyabb fejleszteni. Eközben szokjunk 
hozzá a tool-ok használatához, gyakoroljuk a lehetséges fogásokat. 


Természetesen azt is szem előtt kell tartani, hogy a legnagyobb technoló- 
giai kockázat nem magában egy szoftverkomponensben rejlik, hanem ab- 
ban, hogy az egyes komponensek hogyan illeszkednek egymáshoz, miként 
működnek együtt. (Ez a tény petsze igaz egy fejlesztő team tagjaira is, és a 
team egészére nézve is.) Az előző példára vonatkoztatva: Lehet jól ismerni 
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a Ct- nyelvet, lehet járatosnak lenni a relációs adatbázis kezelésében, de 
ettől még sok nehézséggel járhat a megírt program és az adatbázis összeil- 
lesztése, együttes működtetése. Ezétt is célszerű a fejlesztésben arra töre- 
kedni, hogy a komponensek minél előbb össze legyenek illesztve, hogy 
minél előbb kipróbálhassuk az együttes működésüket. Mint tudjuk, ennek 
az az éttelme, hogy a korábbi változtatások mindig kisebb veszteséggel 
játnak, mint a későbbiek. 

Igen etősen szemmel kell tartani azokat a fejlesztési tésztetületeket, 
amelyeket később nehéz lesz megváltoztatni. Ugyanakkor törekedni kell a 
tetvezés során arra is, hogy az egyes részelemeket minél könnyebben le- 
hessen megváltoztatni. 

Ehhez ilyen kérdéseket érdemes feltenni magunk számára: 


e Mi lesz akkor, ha egy technológiai eszköz nem válik be? 

e Mi lesz akkor, ha két komponens nem illik össze? 

e Mi a valószínűsége annak, hogy valami félresiklik a fejlesztésben, va- 
lami baj lép fel? Mi legyen a megoldás, ha ilyesmi történik? 


Ebben a folyamatban jól fel tudjuk használni a különböző UML-diagtra- 
mokat. Például, az osztálydiagtamok és az együttműködési diagramok (interac- 
tion diagram) igen hasznosak lehetnek abban, hogy megmutatják, hogyan 
kommunikálnak egymással a komponensek. 


Szaktudási kockázatok 


Sokan éttékelik utólag úgy az 00-projektjüket, hogy az volt a gond, hogy 
kevés kiképzést kaptak a résztvevők. Sok helyen sajnálják a pénzt a kikép- 
zésre, és utólag azért fizetnek többet, mert a projekt jóval tovább tartott 
ahhoz képest, hogy nagyobb felkészültséggel vágtak volna bele. 

A kiképzés akkot ér valamit, ha az oktató a fejlesztésben járatos szak- 
ember, aki el tudja mondani, hogy mire kell ügyelni, milyen hibákat kell 
elkerülni, és hogyan lehet bizonyos fontos feladatokat megoldani. (Az a jó, 
ha olyan tanítja, aki csinálja is.) 

Fowler véleménye szerint az objektumortientált fejlesztést nem lehet 
tanfolyamokon, előadásokon megtanulni. A legjobb megoldás az, ha a 
tudást egy olyan személytől sajátítjuk el, aki úgy oktat, hogy közben maga 
is dolgozik a projektben, mégpedig huzamosabb ideig. Ezalatt megmutat- 
Ja, miként kell csinálni egyes dolgokat, tippeket, tanácsokat ad, figyeli, ho- 
gyan oldanak meg problémákat a résztvevők, és közben szükség szetint 
kisebb tanfolyamokat is tatt. 
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Egy ilyen projektoktató személy (zenror) legalább az elején maga is tag- 
ja a fejlesztő teamnek, és tészt vesz a specifikáció kidolgozásában. Az idő 
előrehaladtával egyte inkább csak ellenőtzi, követi a fejlesztést, miközben 
maga egyre kevesebbet dolgozik a fejlesztésen. Legjobb az, ha a vége felé 
már feleslegessé is tud válni. 

Étdemes a projektekhez ilyen külső szakértőket befogadni, és addig 
támaszkodni rájuk, amíg szükséges. Petsze ez komoly költségnövelő té- 
nyező, de a minőség érdekében sokszor megéri ezzel a lehetőséggel élni. 

Az is megoldás lehet, ha csak arra alkalmaznak egy külső szakértőt, hogy 
időszakosan vizsgáljon át egy projektet (pl. havonta), és adjon véleményt 
róla, valamint tanácsokat a továbbfolytatásra. Ugyancsak elterjedt választás 
még az is, amikor a szakértő maga nem vesz részt a projektben semmilyen 
formában, viszont azt ellenőrzi, hogy minden az előírt fejlesztési technoló- 
gia szerint történik-e. Ezt projekt-minőségbiztosításnak nevezik. Több formája 
van: a folyamatos követéstől kezdve az időszakos ellenőtzésig. 

A szaktudási kockázatok csökkentésének egy másik természetes módja 
az önképzés. Fowler szerint érdemes kéthavonta elolvasni egy jó fejlesztési 
szakkönyvet, és ezt állandóan folytatni, annak érdekében, hogy valaki a 
szakmában tudjon maradni. A menedzsmentnek etre is pénzt kell áldozni, 
és a munkatársak számára időt biztosítani az önképzéshez. 


Vállalatpolitikai kockázatok 

Ez elsősorban gazdaságpolitikai, piaci jellegű terület, ahol a jelentkező 
kockázatok döntő mértékben nem műszaki természetűek. Ezen a téren 
minden a vállalti menedzsment üzletpolitikájától, üzleti stratégiájától függ. 
Az idevonatkozó problémák és megoldási módjuk kívül esnek ennek a 
tankönyvnek a keretein. 


2.4.3. Az alaparchitektúra összetétele 


A kidolgozási fázis eredménye abban áll, hogy létrehozzuk a szoftver a/ab- 
architektúráját. Ez az architektúra a következő elemekből tevődik össze: 


e A use case-ek halmaza, ami kifejezi a szoftverre vonatkozó követel- 
ményeket. 

e A tervezési modell, amely a szoftver működésének alapjait tükrözi, és a 
legfontosabb osztályok is leszármaztathatók belőle. 

e A technológiai platform, amely megadja, hogy milyen szoftvertechno- 
lógiai úton, milyen eszközökkel történik a megvalósítása a szoftvernek. 
Ide tartoznak a számítógépes eszközök, az operációs tendszet, a prog- 
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tamozási nyelvek, fejlesztési környezet, tesztelési környezet, felhaszná- 
landó tool-ok stb. 


ar m 


2.4.4. A megépítési fázis teendői 
A kidolgozást követő zzegépítési fázisban iterációk, megoldási ismétlések 
sorozatára van szükség, amelyekben use case-ek vesznek részt. Ez egy 
tervkészítési folyamat, ami arra itányul, hogy mindegyik iterációhoz egy 
use case-t rendelünk. A tetvkészítésben itt meg kell becsülnünk, hogy egy- 
egy use case-hez tattozó iterációs szakasz mennyi ideig fog tartani, hány 
emberhétből fog állni. 
A becslésnek a következő tevékenységekre kell kiterjedni: 


e elemzés, 

e  programtetvezés, 

e  programkódolás, 

e "modultesztelés, 

e modulok integrálása teszteléssel, 
e dokumentálás. 


A szoftverrendszer megépítése ebben a fázisban iterációk sorozatán ke- 
resztül megy végbe, ahol mindegyik iteráció önmagában egy külön mini 
projekt. Ezek a projektek egyben inkrementálisak is, ami abban nyilvánul 
meg, hogy egy iteráció az őt megelőző itetáció use case-éte épül tá, azt 
bővíti, inktementálja. 

A programkódolás önmagában véve is itetatív folyamat. Az egyszer 
már megírt kódot, annak érdekében, hogy egyre jobb legyen a program, 
szükséges lehet újra írni, módosítani. A kód módosítása esetenként ko- 
moly problémákkal járhat. Itt a következőkről van szó: 


e Adva van egy program, amelyhez a fejlesztés alatt új funkciókat kell 
adni, mert ez vetődött fel. Ha egy eredetileg jól megtervezett és jól 
megírt kódhoz utólag teszünk újabb funkciót, akkor az eredeti kód 
, felborulhat", az egész elveszítheti kiindulási rendezettségét. A prog- 
ramban nem volt benne az új funkció, nem volt beleolvasztva, ezért az 
új hozzáírás révén nem tud szervesen, összehangoltan illeszkedni a régi 
programhoz. Ez azért lehet így, mert az esetek többségében az új 
funkciót egyszerűen csak hozzáítják a régi programhoz, annak a tetejé- 
te vagy az aljára ültetik. Ez így nem igazán jó megoldás. A program túl 
bonyolult lesz, és nehézkesen fog működni. 
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e Elvileg egy teljesen jónak tűnő megoldás lenne az, ha a programot 
újraterveznénk, és ezután az új terv alapján újta megírnánk az egész 
kódot. Ez így rendben is volna, viszont túl nagy ráfordítással járna. Az 
új programban új problémák keletkeznének és új hibák lennének. 
Ugyanakkor azonban az is lehetséges, hogy az újtatetvezés hosszabb 
távon meg fogja érni, mett a végül összeállított kód egy kiegyensúlyo- 
zott, jól összehangolt működést fog eredményezni. A jól tervezett, át- 
tekinthető programot tesztelni is könnyebb. 


Mivel két irányban lehet választani, ebben a helyzetben egy mérnöki- 
gazdasági döntés elé nézünk, ahol az optimális kompromisszumot kell 
megtalálnunk. Az egyik irány az, hogy újtatetvezzük, és úgy írjuk meg, a 
másik irány az, hogy a meglevőt írjuk át. A döntésben természetesen a 
kitűzött határidőt is szem előtt kell tartani. A szorító határidő tetmészete- 
sen az újratervezés ellen szól. 


2.4.5. Az átrendezés elve 


A meglevő kód átírásáta is dolgoztak ki olyan irányelveket, amelyek tende- 
zett, áttekinthető módosításokat tudnak etedményezni. Az itt alkalmazott 
megoldást ázrendezésnek (az angolban efactoring) nevezzük. 

Az átrendezésben olyan technikákat, megoldásokat alkalmaznak, ame- 
lyekkel nem változtatják meg a program funkcionalitását, hanem csak a 
belső struktúráját. A struktútaváltoztatással azt érjük el, hogy könnyebb 
lesz áttekinteni a programot, ezáltal könnyebb lesz tovább dolgozni vele. 

Az áttendezési lépések apróbb változtatásokból állnak. Például: egy 
objektum metódusának átnevezése, egy adatmező átmozgatása egyik osz- 
tályból a másikba, vagy két hasonló metódust egy közös osztályban össze- 
vonva megjeleníteni. Jóllehet ezek önmagukban véve kis lépések, mégis 
azzal járnak, hogy nagyon sokat tudnak javítani a programon. Mindezek 
után már biztonságosabban és simábban lehet a programhoz hozzáillesz- 
teni az új funkciókat. 

Az áttendezés végrehajtását a következő elvek, fogások tudják meg- 
könnyíteni: 


e Szigorúan szét kell választani az átrendezést és a funkcióbővítést, va- 
gyis a kettőt nem szabad ugyanabban az időben, együtt végezni. A két 
tevékenységet egymással váltogatva érdemes kivitelezni: átrendezés — 
funkcióbővítés, átrendezés — funkcióbővítés, .. . 
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e Legyen készenlétben az átrendezés előtt a program tesztkészlete. A 
teszteket minél gyakrabban futtassuk le a módosítások során. Ezáltal 
hamar kiderül, hogy nemn lett-e eltontva valami a belenyúlásokkal. 

e Jól körülhatárolt, jól megfogható kis módosításokat hajtsunk végre, és 
mindegyik után rögtön teszteljünk 15. 


Mikor szükséges, ill. célszerű az áttendezés? 


e Ha új funkciót adunk a programhoz, és nehézséget okoz a tégi kódhoz 
igazodni. Ekkor a régi kódot át kell rendezni. 

e Ha nehézséget okoz a régi kód megértése. Az átrendezés elvégzésével 
és a tesztelés végrehajtásával mélyebb betekintést nyerünk a kódba, 
ami a program további felhasználása és fejlesztése szempontjából lesz 
hasznos. 


Előfordulhat, hogy olyan kódot kell átrendezni, amit nem mi írtunk, ha- 
nem valaki más. Ilyenkor, ha még elérhető az eredeti szerző, akkor érde- 
mes vele konzultálni arról, hogy miként is gondolkodott a kód megírása- 
kor. A legjobb az, ha vele együtt, közösen nézzük át a kódot, és azután 
látunk neki az átrtendezésnek. 
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3. Use case modellezés 


A valós üzleti folyamatok végrehajtását támogató szoftvettendszerek a 
folyamatok komplexitásából adódóan nagy bonyolultságú rendszerek. 
Fejlesztésüknél a megrendelő oldaláról, a felhasználói oldalról kell kiindul- 
ni. A felhasználó az, aki részletesen ismeri az elvégzendő feladatokat, is- 
meri a szetvezet működését, azt a környezetet, amelyikben az alkalmazás 
működni fog. Ezen infotmációk és ismeretek birtokában képes megfo- 
galmazni azokat a célokat, amiket a szoftverrendszernek teljesíteni kell. 
Mástészt ő az, aki az alkalmazást működteti, használja. 

Azokat a folyamatokat, amelyeket a különböző szetvezetek valamilyen 
szoftveralkalmazással kívánnak támogatni, a RUP terminológia üzleti fo- 
lyamatként definiálja. A számítógépes támogatást igénylő üzleti folyama- 
tok leírására, az üzleti folyamatokat érintő elemek feltárására a RUP mód- 
szettan üzleti modellezés (Business Modeling) szakaszában kerül sor. 

Az üzleti modellezés a rendszerfejlesztési folyamatnak az a szakasza, 
amelyik még nem a szoftverfejlesztésre koncentrál. Az üzleti modellezés 
során felállított modellek célja, hogy a felhasználók és a fejlesztők számára 
egységes kép alakuljon ki a szetvezettről, a szervezetben zajló folyamatok- 
ról, artól a környezetről, amelyikben a szoftverrendszer működni fog. En- 
nek a munkaszakasznak az eredményeként elkészül az a részletes üzleti 
dokumentum, amelyik összefoglalja a felhasználó igényeit, elképzeléseit, 
pontosan leírja a szervezetben lejátszódó folyamatokat, amelyek számító- 
gépes támogatást igényelnek. A rendszerfejlesztés során ugyanis nemcsak 
szoftvettendszert tetvezünk, a fejlesztés teljes folyamatába beletartozik az 
a szetvezet, amely számára a rendszert fejlesztjük, és azoknak az üzleti 
folyamatoknak a vizsgálata, amelyek számítógépes támogatását akarjuk 
megvalósítani. Az üzleti dokumentum tészletezi a fejlesztés szempontjából 
releváns üzleti folyamatokat, a folyamatok más folyamatokkal való kapcso- 
lódását, pontosan leírja a folyamatok során elvégzendő tevékenységeket, 
meghatározza a folyamatok bemeneteit és kimeneteit, ismetteti a folyama- 
tokban érintett szereplők (üzleti aktorok, üzleti entitások stb.) körét. 

A tendszetrfejlesztési folyamat során a tényleges szoftverfejlesztési 
munka a követelményspecifikáció feladataival kezdődik. Ebben a munka- 
szakaszban az MDA (Model Driven Architeciure — Modell-vezérelt Architektúra) 
szabvány által definiált, a fejlesztendő tendszer struktúráját leíró modellek 
közül a PIM (P/atform Independent Model — Platformfiggetlen Model) tnodell 
kialakításához kezdünk hozzá. 
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A tankönyvben a szoftverfejlesztési lépések közül a követelményspeci- 
fikáció során végrehajtandó tevékenységeket konkrét gyakorlati példákon 
keresztül szemléltetjük. A példa teljes mélységű kidolgozására a tankönyv 
keretein belül nincs lehetőség, azonban a feladatok kidolgozásakor próbál- 
tunk arra koncentrálni, hogy a követelményspecifikáció munkafolyamat, a 
munkafolyamat során végrehajtandó tevékenységek, a végrehajtás mene- 
tének logikája egyértelmű és könnyen követhető legyen. A use case model- 
lezés fejezetben a mintapéldához kapcsolódó szövegtészek kezdetét és 
végét egy vízszintes vonal jelzi, a leírásokat, magyarázó szövegeket a nor- 
mál szövegtől való megkülönböztetés érdekében dőlt betűvel írjuk. 





Mintapélda" 
A SWEPtoducts cég különböző termékek, átuk fotgalmazásával foglalko- 
zik. A cég a termékek értékesítése mellett további szolgáltatásokkal is ren- 
delkezésre áll ügyfelei tészére. Árajánlatot készít, vásárlás esetén biztosítja 
a tetmékek kiszállítását, átvállalva a kiszállítás költségeit. A cég ügyfélcent- 
tikus szellemben működik, amit mi sem bizonyít jobban, mint az Interne- 
ten is elérhető szolgáltatása, az Internetes árajánlat készítésének lehetősé- 
ge. Az Internetes szolgáltatás kiterjesztésével olyan ügyfeleket céloznak 
meg, akik pontosan meg tudják adni a tetmékek megvásárlásához szüksé- 
ges adatokat. Interneten keresztül történő árajánlat szolgáltatás igénybe 
vétele esetén pontosan ismerni kell a tetmékek paramétereit (pl. típus), és 
pontosan meg kell tudni adni a kiválasztott tetmékből kívánt mennyiséget 
(datrabszámot). 

Az árajánlatokkal, a megrendelések kezesével kapcsolatos feladatokat a 
cég ügyfélszolgálati munkatársai látják el. 

A cégnek az árajánlatok összeállítása, az értékesítés mellett el kell látni 
a termékbeszetzéssel és a kiszállítással kapcsolatos feladatokat. 


! A mintapélda kidolgozásakor nem határoztuk meg, hogy a cég konkrétan milyen terüle- 
ten folytatja tevékenységét. Azoknak viszont, akik a gyakorlat példáján könnyebben értik 
meg az elméleti ismereteket, javasoljuk, gondoljanak egy olyan cégre, amelyik különféle 
alkatrészek fotgalmazásával foglalkozik. 
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Üzleti folyamatokat leíró csomagok 
és a közöttük fennálló függőségi kapcsolatok — részlet 


Az üzleti modellezés során összegyűjtött információk rögzítésére is hasz- 
nálhatjuk az UML modelleket. A fenti ábrán UML csomagokat láthatunk, 
amelyek a cég által végzett üzleti folyamatokat modellezik. A csozzag az az 
eszköz az UML-ben, amibe a logikailag összetattozó modellelemeket fog- 
hatjuk össze, különíthetjük el. A folyamatok közötti kapcsolatot függőségi 
viszonyt" (dependency) reprezentáló szaggatott nyilak jelölik. 





3.1. A követelményelemzés szerepe a fejlesztésben 


A szoftverfejlesztési folyamat első lépéseként azt kell meghatározni, mi a 
szoftverfejlesztés célja. A 3.1. ábra azt hivatott szemléltetni, hogy a szoft- 
verfejlesztési tevékenység célja nem más, mint a követelményeknek, a kor- 
látozásoknak, a megszotításoknak (anyagi, erőforrásbeli, emberi stb.) meg- 
felelő szoftvettendszet megtervezése, megvalósítása, üzembe helyezése. 

























s Követelmények d 
er 2? ab 
— TENSEzűl —m 
Üzleti Korlátozások, Fejlesztés során Felhasználói igényeket 
öökumentáció megszorítások elvégzendő feladat kielégítő 


szoftverrendszer 


3.1. ábra. A szoftverfejlesztés összetevői 





2 A függőségi viszonyt a 4.3.7. alpont ismerteti. 
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A kész szoftvettermék kifejlesztéséhez szükséges feladatok végrehajtásá- 
hoz, pontos specifikálásához a felhasználó igényeit és az üzleti folyamatok 
működését összefoglaló üzleti dokumentumból kell kiindulni. A részletes 
üzleti dokumentum alapján kell meghatározni: 


e A megvalósítandó szoftverfunkciók halmazát, céljait és indokait; 

e Atetrvezett rendszer működésére vonatkozó előre látható kotlátozáso- 
kat, amelyeket például a megbízó pénzügyi háttere, pillanatnyi elképze- 
lései támasztanak; 

e Azokat a feltételeket, korlátozásokat, amelyeknek meg kell felelnie a 
fejlesztendő rendszernek ahhoz, hogy késznek mondhassuk és átad- 
hassuk. 


A fejlesztés kezdetén továbbá egyeztetni kell a szakkifejezések használatát 
a félteértések elkerülése étdekében. 


3.1.1. Felhasználói követelmények 


A felhasználónak a szoftverrendszerrel szembeni igényei, elvárásai, azaz a 
felhasználói célok ún. felhasználói követelmények formájában fogalma- 
zódnak meg. A felhasználói követelmények a tetvezett szoftverrendszer külső 
környezetét, viselkedését a felhasználó fogalmaival írják le. A felhasználói 
követelmények leírásának különböző módszerei ismertek. A leírást készít- 
hetjük természetes nyelven, intuitív diagramok tajzolásával, használhatók 
elterjedt ábrázolási technikák pl. folyamatábrák, készíthetünk áttekintő, a 
megéttést segítő táblázatokat. 

A felhasználók, mint megrendelők általában a szoftvettendszernek 
csak az alkalmazás felhasználói oldali képét (felületét), nézetét tudják jól 
leírni. Meg tudják adni, le tudják ítni a szervezetnek, ill. a szervezet műkö- 
désének azt a területét/területeit (altendszer), azt a szervezeti környezetet, 
amelyikben majd a fejlesztendő szoftveralkalmazás működni fog. Megad- 
ják a rendszertől elvárt szolgáltatásokat (szoftverfunkciók, amiket a szoft- 
ver végrehajt), és azokat a feltételeket (megszorításokat), amelyeket a rend- 
szer fejlesztése és majdani működése során be kell tartani. Vannak elkép- 
zeléseik az alkalmazás használatáról, az alkalmazás bemeneteiről és a tőle 
elvárt kimenetekről (pl. listák, bizonylatok formája). A fejlesztő feladata 
lesz, hogy a tendszer viselkedését ezen információk alapján pontosan de- 
finiálja, modellezze. 

A tendszet modellezéséhez, leírásához a fejlesztőnek több feladatot 
kell megoldania. A felhasználói követelményeket (ún. magas szintű célok) 
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kategotizálni kell", közöttük priotitási sortendet kell kialakítani, majd a 
felállított fontossági sortend alapján szükséges mélységben részletesen ki 
kell dolgozni azokat. Csak a pontosan ismert és részletezett felhasználói 
célok ismeretében van lehetőség a szoftverrendszettől elvárt konkrét szol- 
gáltatások meghatározására. A szoftverfejlesztésnek ezen szakaszát köve- 
telményelemzésnek (követelményspecifikációnak) nevezzük. 

Az alkalmazástól elvárt szolgáltatások, szoftvetfunkciók a követel- 
ményspecifikációban funkcionális és nem funkcionális követelmények formájá- 
ban realizálódnak. 


3.1.2. Funkcionális követelmények 


A funkcionális követelmények a szoftvertendszer működésére, a tervezett 
rendszet szolgáltatásaira, a tényleges funkcionalitásta vonatkozó leírások, 
amik a szoftvettendszett kívülről nézve, a felhasználó szemszögéből ítják 
le. Legtöbb esetben nem a felhasználó valódi céljait (magas szintű felhasz- 
nálói célok — felhasználói követelmények) fogalmazzák meg, hanem pon- 
tosan azokat a szolgáltatásokat, amiket a felhasználó igénybe kíván venni, 
azokat a tevékenységeket (funkciók), amiket a felhasználó a rendszerrel el 
akar végezni, végre kíván hajtani. 

A funkcionális követelmények továbbá leírják, hogy a tendszett ért ha- 
tásokra, eseményekre a szoftveralkalmazásnak hogyan kell reagálni, a meg- 
fogalmazott feltételek, a megadott megszorítások függvényében a rend- 
szernek milyen alternatív végrehajtást kell biztosítani, a bekövetkezett kül- 
ső események hatására milyen más funkciókat kell aktivizálni. A fejlesztés- 
nek ebben a szakaszában a szoftvertendszer belső struktúráját, belső mű- 
ködését ún. , fekete doboz"-nak tekintjük. Csak arra koncentrálunk, hogy 
meghúzzuk a fejlesztendő tendszer határát, pontosan definiáljuk, hogy a 
fejlesztendő szoftverrendszernek milyen funkciókat kell megvalósítani, ill. 
mely funkciókat nem kell támogatni. 

A felhasználói célokat a rendszer a követelményspecifikációban defini- 
ált szoftverfunkciók megvalósításával fogja teljesíteni. A szoftverfunkciók 
leírását, a tájuk vonatkozó funkcionális követelményeket UML modellezés 
esetén wse casc-ek formájában modellezzük, ítjuk le. A RUP modelljének 
filozófiáját követve a részletes kidolgozási fázis végére minden felhaszná- 


3 A követelmények kategorizálásnak és minősítésének számos hatékony módszere létezik. 
A szakitodalom a Software Engineering Institute (SED és az ISO által kidolgozott mód- 
szereket javasolja alkalmazni. Az egységesített módszertan a követelmények csoportosítá- 
sát a FURPS-t modell alapján végzi. 
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lói célhoz tartozni kell a funkcionális követelmények egy halmazának, de 
legalább egy use case-nek. 

A fejlesztés sotán vannak szituációk, amikor a felhasználói célok és a 
funkcionális követelmények nem határolhatók el tisztán, egzakt módon. 
Habár az UML nem tattalmaz eszközt a felhasználói célok és a funkcioná- 
lis követelmények konzekvens megkülönböztetésére, kezelésére, a két 
fogalom egyedi értelmezésére vonatkozóan, a fejlesztés hatékony menete 
érdekében viszont, azokat szükséges tudatosan külön kezelni. A felhaszná- 
lói célok és a funkcionális követelmények elhatárolásának érdekében az 
alábbi pontokat étdemes figyelembe venni: 


e elsőként a felhasználói célokat definiáljuk, majd sorra kell venni azo- 
kat a use case-eket, amelyek azokat teljesítik, 

e ahol a funkcionális követelmények és a felhasználói célok nem azonos 
értelmezést kapnak, azokat tudatosan elkülönítve kezeljük, 

e a felhasználói célok az alternatív utak átgondolására adnak lehetőséget, 
amellyel a felhasználói célok teljesíthetők, 

e a funkcionális követelményeket elemzési, tervezési célokra használjuk, 

e arészletes kidolgozási fázis végére minden felhasználói célhoz tartoz- 
ni kell a funkcionális követelmények (use case-ek) egy bizonyos kész- 
letének. 


A működésnek azonban vannak kotlátai, feltételei, megszorítások, ame- 
lyeket a tervezés során szintén figyelembe kell venni. A működést befolyá- 
soló elemek halmazát ze funkcionális követelményeknek nevezzük. 


3.1.3. Nem funkcionális követelmények 


A felhasználói célok összegyűjtése során találkozunk olyan megfogalmazá- 
sokkal, amelyek nem konktétan a szoftvettendszer működésére, a szoft- 
vertendszetr által megvalósítandó szolgáltatásokra irányulnak, hanem a 
szoftvetrrendszer működését befolyásolják. Ilyenek a működés környezeté- 
te vonatkozó kényszerek, feltételek. Ezeket a követelményeket nem funk- 
cionális követelményeknek nevezzük. 

A nem funkcionális követelmények vonatkozhatnak a tendszer egészé- 
te, vagy egy tészére, vagy akár egy konkrét funkcionális követelményre. A 
nem funkcionális követelmények halmazába tartoznak olyan megkötések, 
feltételek, megszorítások, mint például: 


e  aszoftvertendszer hatdver- és szoftverkörnyezete, 
e at rendszer válaszideje, 
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a rendszer megbízhatósága, 
biztonsági szempontból a mentések gyakorisága, 
tendszetösszeomlással kapcsolatos követelmények, 


a szoftverrendszer fejlesztésére vonatkozóan technológiai, technikai és 
egyéb előírások (a fejlesztési folyamat modelljeinek leírására az UML 
nyelvet kell használni) stb. 


A funkcionális és nem funkcionális követelmények meghatározáshoz és 
dokumentálásához használhatjuk a ,,Követelményjegyzék-bejegyzés" formalapot. 
A 3.2. ábrában bemutatott minta-formalap segít a követelmények ponto- 


Követelményjegyzék bejegyzés 


Prjeltírendszer [Szerző fp fverző [Alapot [oda] 
Priortás ———— [Tulajdonos Követelmény AZ 
Funkcionális követelmény 


Nem funkcionális követelmény(ek) 


[ 


Megjegyzések! javasolt megoldási módok 
apcsolódó iratok 


apcsolódó követelmények 


Megoldás 


3.2. ábra. Követelményjegyzék-bejegyzés formalap 
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sabb, precízebb, ezáltal ellenőrizhetőbb követelményekké való formálásá- 
ban. A fejlesztési munka korai szakaszában nem biztos, hogy a formalap 
minden tészét ki tudjuk tölteni, a fejlesztés elején lesznek hiányosságok. A 
fejlesztés előrehaladtával, egyte több infotmáció birtokában a követelmé- 
nyekhez készített formalapot pontosítjuk, szükség esetén módosítjuk egé- 
szen addig a pontig, amikor a felhasználók és elemzők egyetértéste nem 
jutnak abban, hogy a formalap már teljes leírását adja a leendő rendszernek. 

,, Követelményjegyzék bejegyzés"? formalap kitöltését 3.1. táblázatban 
összefoglalt kitöltési útmutató segíti. A segédlet részletes leírást, magyará- 
zatot ad a formalapon szereplő minden mezőre. 


3.1. táblázat. Kitöltési útmutató 





Követelmény AZ 


egyedi azonosító 











Forrás a követelmény forrása, lehet személy, dokumentum stb. 

Prioritás a követelmény prioritása, a felhasználó szetint, pl. ma- 
gas/alacsony, vagy kötelező/ javasolt/ választható 

Tulajdonos felhasználó vagy felhasználói szervezet, aki a követel- 


ménnyel kapcsolatos egyezkedésétt felelős 





Funkcionális köve- 
telmény 


az igényelt lehetőség vagy szolgáltatás leírása 





Nem funkcionális 
követelmény 


leírás, lehetőség szerint cél értékkel, elfogadható tarto- 
mánnyal (minimum, maximum), minősítő megjegyzéssel 








solt megoldási módok 


Haszon: a követelmény kielégítéséből származó várható hasznok 
leírása 
Megjegyzések/ java-  ] lehetséges megoldások leírása, általános megjegyzések 





Kapcsolódó iratok 


hivatkozás kapcsolódó dokumentumokra, mint például 
felhasználói dokumentumok, projektalapító okirat, adat- 
folyamábra stb. 





Kapcsolódó követel- 
mények 


ha különböző követelmények hatnak egymásra, vagy 
kizárják egymást, akkor a hivatkozást fel kell jegyezni 
mindkét oldalon, hogy esetleges változtatás esetén fel 
lehessen mérni a hatást a mások oldalon 





Megoldás 








a követelmény megoldási módjának feljegyzése, például 
egy konkrét funkcióleírásra való hivatkozással. Ha egy 
követelményt nem fogunk kielégíteni, akkor itt kell 
felírni az okait. 
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3.1.4. Szakterületi követelmények 


A követelmények csopottosításakor, strukturálásakor találkozunk olyan 
követelményekkel, amelyek nem közvetlenül a felhasználói igényekből 
származtatva a tetvezett szoftvertendszer működésére (funkcionalitására), 
ill. a működés kötnyezetéte vonatkoznak, hanem a leendő rendszer által 
kiszolgált szaktetület követelményeiből adódnak. Ezek a követelmények a 
tetvezett rendszer szakterületén alkalmazott előírásokat, megszorításokat 
(pl. számítási előírások, az adott szakterület működéséte vonatkozó jog- 
szabályok stb.) foglalják össze. A követelményeknek ezt a csopottját sza£k- 
területi követelményeknek (Domain Reguirements) hívjuk. 

A szakterületi követelményeket összefoglaló dokumentum tartalmaz- 
hat olyan, a szaktetület sajátosságaiból adódó előírásokat, amelyek: 


e újabb funkcionális és nem funkcionális követelményeket generálnak, 
vagy 
e a már megfogalmazott követelményekre korlátozásokat írnak elő, de 
előfordulhat az is, hogy 
e pontosan meghatározzák egy szoftverfunkció konkrét végrehajtási 
módját. 
A szaktetületi követelmények — az alkalmazási terület sajátosságait erősen 
magukon hotdozva — sok esetben hiányosak. A hiányosság fő oka, hogy a 
szakterület képviselői számára a szaktetületen alkalmazott szabályok, elő- 
írások olyannyira nyilvánvalóak és egyértelműek (implicitás), hogy fel sem 
metül a szándék azoknak a fejlesztés során tötténő megemlítésére, így 
azok pontos éttelmezésére, magyarázatára sem kerül sor. Mindehhez hoz- 
zátársul az is, hogy a szakmaterület által használt szaknyelv (szakzsatgon) a 
fejlesztők számára nehezen érthető. Az implicitás és a két szakma (fejlesz- 
tő—felhasználó) szaknyelvének különbözősége sok esetben végzetes félre- 
értésekhez vezethet, aminek az eredményeként olyan termék kerülhet ki- 
fejlesztéste, ami nem az eredeti céloknak megfelelően fog működni. A 
fentiek elkerülése érdekében a szakterülette vonatkozó sajátosságokat, 
előírásokat, szabályokat a fejlesztési munka során megfelelő hangsúllyal 
kell kezelni, a szakmaspecifikus kifejezéseket pedig — etre a célra tendsze- 
resített — külön fogalomszótátban (értelmező szótár) célszerű dokumen- 
tálni. 
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A követelményeknek funkcionális, nem funkcionális és szakterületi 
szempontok alapján történő elkülönítése abban játszik nagy szerepet, hogy 
átgondoljuk 


e a tervezett rendszer működését, a működési körülményeket (előítások, 
szakterületi szabályok stb.) 

e milyen funkcionalitást, milyen felületet biztosítson a leendő szoftver a 
felhasználó felé, milyen belső funkciókat kell teljesítenie ahhoz, hogy a 
felhasználó igényeit kielégítse, és működés közben milyen előírásokat, 
szabályokat kell alkalmaznia, betattania. 





Felhasználói célok és követelmények leírása 


A SWEPtoducts olyan szoftverrendszer kifejlesztésére adott megbízást, 
amelyik biztosítja az árajánlatok készítését, a megrendelésekkel (az értéke- 
sítéssel) kapcsolatos feladatok ellátását. 

Az alábbiakban egy olyan dokumentum tészletet mutatunk be, amely 
összefoglalja, hogy a megrendelő milyen insttukciókat adott az árajánlat 
kezelési és a megrendelés (értékesítés) szolgáltatás megvalósítására vonat- 
kozóan. A megrendelő által felsorakoztatott igények adják a felhasználói 
követelmények halmazát. 

Az árajánlat kezelési szolgáltatásta vonatkozó felhasználói követelmé- 
nyek: 


e Az ügyfelek kérhetnek árajánlatot a cég ügyfélszolgálatánál, amiket a 
cég munkatátsai állítanak össze, de igénybe vehetik az Internetes ár- 
ajánlat szolgáltatást is. 

e A cég megkülönbözteti a vásárlókat. Vannak az , átlagos" vásátlók, és a 
nagyvásátlók. A cég a nagyvásárlókat kiemelt ügyfélként tartja nyilván: 
-— A nagyvásátlóknak a megrendelések pénzügyi teljesítésére 30 na- 

pos átfutási idő áll tendelkezésre. Az , átlagosként? nyilvántartott 
vásátlók a helyszínen fizetnek, készpénzben vagy bankkárttyás fize- 
téssel teljesítenek. 

- A nagyvásátlók a vásárlási volumen függvényében kedvezményt 
(törzsvásárlói kedvezmény) kapnak. A kedvezmény mértékének 
meghatározása és jóváhagyása a Kereskedelmi menedzser feladat- 
körébe tattozik. Abban az esetben viszont, ha az ügyfél három ko- 
rábbi megrendelését pénzügyileg nem teljesítette, a törzsvásátlói 
kedvezményét elveszíti. 
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e Az árajánlatok, az abban feltüntetett árak, kedvezmények az árajánlat 
készítésének idejétől számított hat hónapig étvényesek. 

e Az ügyfeleknek lehetőségük van az interneten készített árajánlatok 
kinyomtatására. 


A megrendelés (értékesítés) szolgáltatásra vonatkozó felhasználói köve- 
telmények: 


e A fejlesztendő szoftvert képes az ügyféltendelések (vásátlások) kezelé- 
sére. 

e  Vásárolni csak a cég ügyfélszolgálatánál lehet. Intetneten csak árajánlat 
készítésére van lehetőség. 

e Amennyiben egy ügyfél rendelkezik érvényes árajánlattal, a rendszer- 
ben kell lenni olyan funkciónak, amelyik az árajánlatot vásárlá- 
si/megrendelési tranzakcióvá alakítja, konvertálja. Erre a megoldásra 
azért van szükség, hogy az átajánlatban szereplő adatokat a cég mun- 
katársainak vásárlás esetén ne kelljen újból felvenni, rögzíteni. 





A követelmények szetepe meghatározó a majdan működő rendszer minő- 
sége szempontjából. Emiatt rendkívül fontos, hogy kiemelt figyelmet for- 
dítsunk a szoftvetfejlesztési folyamat korai fázisában a követelmények 
teljes körű feltárására. Ügyelni kell azonban arra, hogy a követelményeket 
a fejlesztés kezdetén definiált célok alapján csak a megfelelő mélységig 
részletezzük ki. 

A gyakotlat azt mutatja, hogy a fejlesztés során a megrendelőnek, a fel- 
használónak újabb elképzelései, igényei merülhetnek fel. A korábban spe- 
cifikált követelmények így a fejlesztés folyamán változhatnak, módosul- 
hatnak. A modern rendszerfejlesztési módszettanok szerint (így a RUP 
szerint is) a rendszert fel kell készíteni a követelmények változásának kö- 
vetésére. 

A követelményspecifikáció során az igények változásából adódó mó- 
dosításokat, ill. a felmerült új igényeket első lépésben elemezni kell, majd 
meg kell vizsgálni, hogy a felmerült változtatások és az új igények milyen 
hatással lesznek a már felállított követelménytrendszetre. A vizsgálat ered- 
ményének kiéttékelése után lehet csak dönteni a változások megvalósítha- 
tóságáról. 
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3.2. A use case modell kialakítása 


A RUP módszettan szerint a követelményspecifikáció munkaszakasz egyik 
legfontosabb feladata a fejlesztendő rendszer működését leíró use case 
modell elkészítése. A use case modellben a tendszer működésére vonatko- 
zó funkcionális követelményeket use case-ek formájában írjuk le, ill. use 
case-ekhez kapcsolva gyűjtjük össze. A use case modellezés alapjául szol- 
gáló use case-eknek kulcsszerepe van a tendszerfejlesztési folyamat vala- 
mennyi fázisában. Végigkísérik a teljes fejlesztési folyamatot. A use case 
modellt használjuk, finomítjuk tovább az elemzés, a tervezés, az imple- 
mentáció és végül a tesztelés sotán. Továbbá a modellben felállított köve- 
telményhalmaz az alapja a fejlesztés teljes életciklusában folytatott folya- 
matos ellenőtzési és kiértékelési feladatoknak. 

A követelményspecifikáció végére előálló use case modell a rendszer 
tervezett funkcionális működését, a rendszer viselkedését írja le a tend- 
szert kívülről, a felhasználó szemszögéből nézve. A modell három építő- 
elemet tartalmaz: 


e se case-ek (szoftvetfunkciók — szolgáltatások), amiket a fejlesztendő 
szoftvertendszetnek meg kell valósítani, 

e  ak£rorok, akik/amik a tendszer határán kívül vannak, a rendszerrel kap- 
csolatba kerülnek, hogy a tendszetrel feladatokat (szoftvetrfunkciók) 
hajtsanak végre, 

e a kapcsolat az aktotok és use case-ek közötti viszonyrendszert definiálja. 


A témával foglalkozó irodalom a use case modell kialakításakor első lé- 
pésben a use case-ek feltárását, egy use case listát javasol elkészíteni. A 
gyakorlat, a szakmai tapasztalatok azonban azt mutatják, hogy sok esetben 
elég nehéz a use case-ek listájának meghatározása. Első lépésben köny- 
nyebb megtalálni, azono-sítani a rendszerrel kapcsolatba kerülő szereplő- 
ket, aktorokat. Ha már ismerjük az aktorokat, azokhoz egyszerűbb hozzá- 
társítani az általuk kezdeményezett, ill. végrehajtott use case-eket (funkció- 
kat). A tankönyv a gyakotlatot követve elsőként az aktorokra vonatkozó 
ismereteket tekinti át, majd a use case-eket részletezi. 


3.2.1. Aktorok 


A felhasználóval folytatott beszélgetések, a felhasználói célokat összefog- 
laló dokumentumok alapján körvonalazódik, hogy mik, vagy kik az érde- 
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keltek" a rendszer határán kívül, amik/akik közvetlenül kapcsolatba kerül- 
nek, kommunikálnak a leendő szoftvertendszetrrel. Az érdekelteket a use 
case modellben aktornak vagy szereplőnek nevezzük. A szereplő elneve- 
zés helyett gyakran találkozhatunk a szerepkör kifejezéssel is. A tendszer 
felhasználói ugyanis meghatározott feladatkört (szetepet, jogosultságot) 
betöltve lépnek kapcsolatba a rendszerrel, egy konktét szerepkött betöltve 
használhatják a szoftverrendszett és annak szolgáltatásait. 

Az aktor egy szerep, amit az érdekelt játszik/végrehajt a rendszerrel 
folytatott interakcióban. A rendszet szeteplője, aktora valaki vagy valami a 
rendszer határán kívül, aki/ami kapcsolatba kerül a rendszerrel, azzal fel- 
adatot hajt végte, vagy a rendszernek egy adott szolgáltatását veszi igény- 
be. Az aktotok nem kizárólag személyek, lehetnek tárgyak, gépek- 
berendezések, üzleti egységek, vagy a rendszerrel kapcsolatot létesítő va- 
lamely külső rendszerek, rendszerkomponensek. 


Az aktorok sajátosságai 


e Egy felhasználó többfajta szerepet is játszhat/végezhet, többféle sze- 
tepkötben lehet; egy szerepkört több felhasználó is betölthet (a rend- 
szerben sohasem lehet két azonos szetepkött betöltő aktor). 

e Az aktotoknak a rendszerrel kapcsolatban igényeik vannak, feladatok 
végrehajtását kezdeményezik, vagy a tendszer által nyújtott funkciók, 
szolgáltatások megvalósításában vesznek tészt. 


A feladatok végrehajtását kezdeményező szereplőket kezdeményező szereplő- 
nek, a funkció (use case) megvalósításában tészt vevőket részévevő szereplő- 
nek hívjuk. Egy use case-t mindig csak egy aktor kezdeményezhet, egy use 
case megvalósításában viszont több aktor is részt vehet. 


e Az UML modellben az aktor nem objektum, hanem egy osztályszetű 
modellelem, amit az UML classifier minősítéssel azonosít, Clactor25 
sztereotípiával" ít le; 

e Az aktor grafikus szimbóluma egy pálcikaember (lásd 3.3. ábra). 


§ A követelményspecifikáció során azonosított érdekeltek köre (pl. a cég ügyfélszolgálati 
munkatársai, mint a szoftvertendszer használói) nem feltétlenül, sőt sok esetben abszolút 
nem egyezik meg az üzleti modellezés során felállított érdekeltek (pl. a cég vezetése, 
amely tendett ítt ki a szoftverrendszer fejlesztésére) listájával. 

5 Sztereotípia: A modellelemek magas szintű tipizálása. Lásd részletesen a 4.3.5. alpontot. 
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aktor 
(szereplő) 


3.3. ábra. Az aktor UML-szimbóluma 


Az aktorok megtalálásának módja 


A felhasználói célokat összefoglaló dokumentumokból kiketessük a főne- 
veket. A kereséskor a releváns szeteplők meghatározása érdekében célsze- 


tű arra koncentrálni, hogy: 


Ki/mi használja a rendszert? 


Kik működtetik a rendszett, kik felelnek a rendszer karbantattási és 
adminisztrációs feladatainak végrehajtásáért? 


Kinek a hatáskörébe tartozik a biztonságkezelés, tendszetvédelem? 


Létezik a rendszerben folyamatfigyelés, monitoting folyamat (moni- 
toring process), amelyik hiba esetén újraindítja a tendszert? 


Kommunikál-e az új tendszer más tendszetekkel? Stb. 


er 


A rendszert szereplőinek specifikálásra vonatkozó előírások 


a rendszerrel közvetlenül kapcsolatba kerülő, a rendszert használó 
érdekelteket (személyek, dolgok, más rendszerek, rendszertkomponen- 
sek) a feladatkörre, szetepkörre utaló névvel kell ellátni, azonosítani, 

az aktorok neve egy tetszőleges karaktetsor, 

az aktor nevének megválasztásakor ügyeljünk atta, hogy az aktor neve 
azonosítsa a use case-t kezdeményező, vagy a use case megvalósításá- 
ban részt vevő szereplőt, 

az aktor nevét a szimbólum alá írjuk, 

a specifikációban töviden meg kell adni, hogy az aktor mit várt el a 
tetvezett szoftvetrendszettől, mi a felelőssége. 
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Az aktorok azonosítása 


A feladat megfogalmazásából azonnal látható, hogy a rendszert potenciáli- 
san az ügyfelek és a cég munkatársai fogják használni. A tendszernek biz- 
tosítani kell, hogy az ügyfelek interneten állíthassanak össze árajánlatokat. 
A munkatársak az árajánlat-készítés mellett az ügyfélnyilvántartással, a 
megrendelésekkel (értékesítésseh kapcsolatos feladatokat látják el. A ki- 
emelt nagyvásátlók részére a törzsvásárlói kedvezmények kezelése a cég 
menedzserének felelősségi körébe tattozik. A számlák egy külön Számlá- 
zási modulban készülnek. Ez azt jelenti, hogy meg kell oldani az új tend- 
szetnek a Számlázási modullal való együttműködését, kommunikációját. A 
korábban meghatározott felhasználói követelmények, és a fenti logikai 
levezetés alapján a rendszerben négy aktort definiálhatunk: a Kereskedő, 
az Ügyfél, a Kereskedelmi menedzser és a Számlázó rendszer aktorokat. 


5 T et 

Z Ma 

Ugyfél Kereskedő Kereskedelmi Számlázó 
menedzser rendszer 





A tendszer aktorainak, és azok elvárásainak ismeretében már telatíve 
könnyebb meghatározni a use case-eket. 


3.2.2. Use case-ek 


A use case-ek a fejlesztendő szoftverrendszettől a felhasználó által elvárt, 
megkövetelt viselkedés(ek)t, a tendszer által nyújtott szolgáltatásokat írják 
le. A use case fogalmának pontos definiálására az itodalomban számos 
tetminológia létezik: 


e Feladatok, funkciók kisebb vagy nagyobb egységeinek specifikálására 
szolgáló grafikus ábrázolási technika — a use case-ek valójában a rendszer 
funkcionalitását, viselkedését fejezik ki a rendszert kívülről szemlélve. 

e A rendszerrel kapcsolatban feltárt use case-ek megadják a fejlesztendő 
rendszert külső képét. 

e A rendszer kívülről látható funkciói, ún. kapcsolódási pontok a szoft- 
vettendszert használók és a szoftvertendszer között. 

e Tevékenységek specifikációja. 
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A use case a felhasználó és a számítógépes tendszet közötti interakció defi- 
niálására szolgáló modellelem. Tipikusan a szoftvert és a felhasználó (ak- 
tor) között lezajló kommunikáció, üzenetváltás lépéseit írja le a felhasználó 
szemszögéből. Egy use case pontosan azt határozza meg, hogy a felhasz- 
náló (aktor) MIT akar a szoftverrel végrehajtani, milyen célt kíván megva- 
lósítani, ugyanakkor nem tér ki a megvalósítás, a HOGYAN tészleteite. 

A use case-ek definiálásához hozzátattozik a use case nevének meg- 
adása, valamint egy leírás elkészítése, amely tartalmazza a use case-ben 
definiált működés végrehajtása során elvégzett lépéseket, megvalósított 
műveleteket. Ezt a leírást általában forgatókönyvnek nevezzük. A trend- 
szetfejlesztés során ezt a leírást bővítjük, sttukturáljuk, ill. elkészítjük a use 
case-t strukturáltan leíró aktivitási diagramot. 

A követelményspecifikáció munkaszakaszban definiált use case-eket a 
szakirodalom fekete doboz wse case-eknek (black-box use case) is nevezi. A feke- 
te doboz jelző azt hangsúlyozza, hogy a fejlesztésnek ebben a szakaszában 
nem térünk ki a rendszer, a tendszetkomponensek belső működésére. A 
cél csak a tendszer viselkedésének specifikálása a tendszert külső szemmel 
nézve. A követelményspecifikáció során folytatott use case modellezésnek 
fontos célja a rendszer határainak meghúzása, azaz annak definiálása, hogy 
a leendő rendszer milyen funkciókat tud végrehajtani, és melyeket nem. A 
3.2. táblázat az ÁrajánlatotKészít Weben use case példáján keresztül de- 
monstrálja a tendszer szokásos külső viselkedésének leírását és a belső 
működés specifikálását. 


3.2. táblázat. Példa egy use case esetén szokásos külső viselkedés leírásra 
és egy hozzá készített belső viselkedés leírásra 





Black-box módszert a rendszer 
(külső) viselkedésének leírására 


Belső működés specifikálása 





ÁrajánlatotkKészít Weben use case: 
Végrehajtásakor az Ügyfél megadja 
az Arajánlat összeállításához szük- 
séges adatokat, majd a rendszer 
elkészíti az árajánlatot. 








ÁrajánlatotKészít Weben use case: 


A rendszer ellenőrzi a megadott 
adatokat, és ha az adatok helyesek, 
akkor a rendszer az adatbázisba, az 
árajánlat táblába beszúr egy új sott, 
rekordot. 
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A use case-ekre vonatkozó jellemzők, sajátosságok 


e A fejlesztendő rendszer szempontjából megkülönböztetünk architek- 
tirálisan fontos, egyéb és tendszetridegen use case-eket: 

— Az arcbitekturálisan fontos use case-ek az alkalmazás architektú-rájának 
meghatározása szempontjából kritikusak, szignifikánsak. Ezek a use 
case-ek valósítják meg a rendszer fő szolgáltatásait. Biztosítják a 
rendszer alapműködését, a felhasználó által definiált fő feladatokat. 

— Az alap use case-ek mellett vannak ún. egyéb wse case-ek, amelyek ke- 
vésbé kritikusak a teljes tendszer működése szempontjából. A fej- 
lesztés sotán a munkát célszerű a nagyobb prioritással rendelkező, 
architektúrálisan fontos use case-ek kidolgozásával kezdeni, majd 
később foglalkozni az ún. kevésbé kritikus, egyéb funkciókkal. Az 
architekturálisan fontos és egyéb use case-ek együttes halmaza adja 
meg a szoftverrendszer határát. 

— A rendszet határának pontos meghúzása a követelményelemzés so- 
rán történik meg. Ilyenkor előfordul, hogy a korábban definiált use 
case-ek közül néhány kikerül a tendszet végső követelményhalma- 
zából. Ezekkel a use case-ekkel a fejlesztés további szakaszaiban 
nem szabad foglalkozni. A fejlesztendő rendszer szempontjából 
ezeket a use case-eket rendszeridegen use case-eknek hívjuk. 

e Egy use case lehet , kicsi vagy nagy": 

A use case-ek-hez készített forgatókönyvek (lásd később) a rendszer 

funkcionalitását különböző megközelítésben és különböző szinteken 

fejezik ki. Mivel egy use case absztrakciós szintjének mélységét mindig 
az határozza meg, hogy azt milyen céllal, és kinek készítjük, így biízo- 
nyos éttelemben más-más részletezettséggel és pontosító infotmációk- 
kal készítünk use case-eket a felhasználókkal való kommunikációra, 
mást a fejlesztők közötti kommunikáció leítására. A RUP módszettan 
logikáját követve a use case-ek feltárása a részletes kidolgozási fázisban 
kezdődik, de azok tészletes kifejtéséte nem mindig ebben a fejlesztési 
szakaszban kerül sor. A use case-ek finomítására, a fejlesztés későbbi 
szakaszaiban történő teljes mélységű kifejtetéséte a RUP által követett 
iteratív fejlesztési paradigma ad lehetőséget. 

e Egy use case konktét célt teljesít, valósít meg az aktor számára: 

Ebben az éttelemben a use case-eket kétfajta megközelítésben értel- 

mezzük. Beszélhetünk rendszer intetakciókról (a rendszer interakciók 

megnevezése szinonim a korábban használt funkcionális követelmé- 
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nyek elnevezéssel), és megkülönböztetünk felhasználói célokat. A use 
case-ek ilyen fajta megkülönböztetésére az ad lehetőséget, hogy a defi- 
niált use case-ek milyen alapossággal írják le a követelményeket, a 
megvalósítandó célokat. A 3.3. táblázatban olvasható példarészlet egy 
szövegszetkesztő szoftver fejlesztésekor felmerülő potenciális use 
case-eket tartalmazza, elkülönítve a felhasználói célokat a rendszer in- 
terakcióktól (funkcionális követelmények). 


3.3. táblázat. Rendszer interakciók és felhasználói célok [12] 





Felhasználói célok — user goals 


Rendszer interakciók — 
system interaction 








, ensure consistent formatting  1— , define a style"; , change a 
for a document"; style"; 

, make one docsaments fotmat ]— , move a style from one 
the same as another"; document to another"; 








A fenti kettőség nem minden esetben határolható el egzakt módon: ,,zz- 
dex the document"; 








A use case-eket minden esetben az aktorok kezdeményezik: 

Az informatikai alkalmazásokat a felhasználók (a rendszer aktorai 

működtetik, használják feladatok végtehajtásához. A fejlesztés során a 

felhasználók szoftverrel szembeni igényeit use case-ek formájában ír- 

juk le. Az elérendő célok szempontjából releváns use case-ek megtalá- 
lására a gyakotlatban számos módszer létezik. Megoldással szolgálnak: 

— az adott tetületre jellemző felhasználóval való folytatott közös be- 
szélgetések, interjúk, 

— kérdőívek használata csopottos felmérés esetén, 

—  brainstorming (ötletbötze) módszer alkalmazása. Használata első- 
sorban új fejlesztések esetén hasznos, vagy nehezen megfogható, 
leírható problémák megoldásakor. 

—  vitakurzusok a korábbi beszélgetések során definiált dolgok (fel- 
adatok, funkciók) megvitatására, tisztázására, 

— egyszerű, ún. favágó módszert: a célokat megfogalmazó dokumen- 
tumokból kigyűjtjük az igéket. 
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A use case-ek specifikálásra vonatkozó szabályok 


e A követelményspecifikáció során meghatározott funkcionális követel- 
ményeket leíró use case-eket a funkciójellegre utaló névvel kell ellátni, 
azonosítani. 

e A use case-t azonosító név egy tetszőleges karaktersort. 

e A use case neve kettős szerepet tölt be. Azonosítja a diszkrét feladatot, 
amit a rendszernek teljesíteni kell, másrészt a megnevezés az adott use 
case-t meg is különbözteti a többi use case-től. 

e A use case-eket (diszkrét feladat, funkció) az UML modellező nyelv 
szabályai szerint grafikusan egy ellipszis szimbólum jelöli (lásd 3.4. ábra). 

e A use case (funkció) nevét az ellipszis alá írva adjuk meg. 


e 
use case/funkció 


3.4. ábra. A use case szimbóluma UML-ben 


e Minden use case-hez tartozni kell egy use case leírásnak. 


A fejlesztés sotán minden use case-hez készül egy részletes leítás. A tész- 
letes leírásban a felhasználó szemszögéből rögzítjük a felhasználó és a 
rendszer között zajló üzenetváltás (párbeszéd) lépéseit. Egy use case 
azonban nemcsak a szokásos (normál) működéssel hajtódhat végte. A use 
case szokásos működését a use case normál lefutásának, más szóval alap- 
folyamatnak hívjuk. A működésnek lehetnek különleges, alternatív esetei 
(pl. hibás működés), ezek az alfolyamatok. A fejlesztés során minden use 
case esetén fel kell tárni az összes alternatív lefutási menetet. A use case-ek 
normál és altetnatív működését külön fotgatókönyvekben rögzítjük. 

A forgatókönyv", más szóval szrenárió a use case egy konktét végrehajtása, 
lefutása, a use case egy példánya (instanciája). A use case-ben definiált 
működés lépésenkénti, ún. step-by-step végrehajtását tattalmazza a fel- 


6 A forgatókönyv nem az UML és nem a RUP tartozéka. Már a hagyományos és korai 
00-fejlesztésekben is alkalmaztak forgatókönyveket a feladatok végrehajtási lépéseinek 
leírásához, használatuk azonban informális jellegű volt. A fortgatókönyvszetű leírások 
nagyban segítették a feladatok megértését, lehetőséget adtak a bonyolultabb problémák 
átgondolására, majd azok logikai strukturálására. 
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használó szemszögéből. Egy use case-hez az altetnatív működések miatt 
több forgatókönyv készülhet, de egy biztosan. A forgatókönyv készítése- 
kor a tendszer és a felhasználó között zajló üzenetváltásokat a felhasználó 
szerepében célszetű megfogalmazni, hiszen a felhasználó fogja az alkalma- 
zást használni. Az üzenetváltások leírásakor a MII-te koncentráljunk, azt 
írjuk le, hogy a use case működéskor MI tötténik, milyen tevékenységek 
zajlanak, és ne térjünk ki a HOGYAN tészleteire, a megvalósítás módjára. 
A fotgatókönyvben elsőként a use case-ben definiált működés normál 
végrehajtását írjuk le, de el kell készíteni az alternatív esetekhez tartozó 
fotgatókönyveket is. 

A fotgatókönyv készítésére nincsenek szigorú formai előírások, meg- 
kötések. A fotgatókönyvben a use case működését, vagyis az egymás után 
zajló tevékenységeket szöveges formában, mondatszerűen fogalmazzuk 
meg. A forgatókönyv tattalma (egy lehetséges alternatíva): 


e a feladat rövid értelmezése, 

e az alternatív útvonalak meghatározása, 

e a végrehajtásban résztvevő szereplők meghatározása, 
e a közös feladatok kiválasztása. 


A fotgatókönyv készítésekor érdemes megvizsgálni a következőket: 


e Hogyan kezdődik a use case? 

e Hogyan ét véget a use case? 

e — Milyen kölcsönhatások tötténnek az aktor és a use case között? 
e Milyen adatok cserélődnek a use case és az aktor között? 

e Milyen ismétlődő viselkedést hajt végre a use case? 


A követelményspecifikáció munkaszakaszban a use case-ekhez készített 
fotgatókönyvek összessége tisztán és érthetően modellezi a szoftvet mű- 
ködését. A use case-ek teljes részletezettségű kifejtésére az elemzés /terve- 
zés fázisban kerül sor, ahol már a megvalósítás (use case tealization) mi- 
kéntjére fókuszálunk, a HOGYAN kétdésre helyezzük a hangsúlyt. Ebben 
a szakaszban térünk át az implementációs részletekre. 
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Use case-ek definiálása 


A felhasználói követelmények és a tendszer szereplőinek ismeretében ha- 
tározzuk meg a funkcionális követelményeket leíró use case-eket. Vegyük 
sorra a tendszetben definiált aktorokat, és határozzuk meg, hogy milyen 
use case-ek végrehajtását kezdeményezik, ill. mely funkciók végtrehajtásá- 
ban vesznek részt, működnek közte. 


e A Kereskedő végzi az ügyfelek nyilvántartását, árajánlatot készít, szám- 
lát állít ki, a megrendelésekkel (értékesítés) kapcsolatos feladatok fele- 
lőse. A számlakészítés a Számlázó rendszerben történik. A számlaké- 
szítéshez szükséges adatokat a Számlázó rendszer az új rendszerből 
veszi, ezért meg kell oldani az új rendszer és a Számlázási modul 


kommunikációját is. 
E 
a 
ÜgyfélTörzsadatotKezel 


E 
ee ÁrajánlatotkKezel 


czeaetl 


AT [sz 








at 6) 
ba sz pi 
SzámlátKészít 
Számlázó rendszer 


e Az Ügyfél interneten árajánlatot tud összeállítani. Az Ügyfélnek, hogy 
igénybe vegye a cég webes árajánlat készítési szolgáltatását, tegisztrálni 
kell magát a rendszerbe. A regiszttáció során ki kell tölteni egy Re- 
gisztrációs lapot. A regisztráció elfogadásával az Ügyfél bekerül a cég 
ügyfélnyilvántartásába. Az Ügyfél megtekintheti a korábban készített 
árajánlatokat (a rendszer az árajánlatokat csak a készítés időpontjától 
számított hat hónapig tárolja). 
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Ez 
B 
ÁrajánlatotKészít 
. Weben 
Zs á 
ho 
ÁrajánlatotLekérdez 
. Weben 
za 
zzz 
ÁrajánlatotNyomtat 
. Weben 


e A Kereskedelmi menedzser kezeli a cég kiemelt ügyfeleit, a nagyvását- 
lókat. A nagyvásárlóknak adott kedvezmények mértékének (meghatá- 
tozása) jóváhagyása, tötlése tattozik hatáskörébe. 


hl 
fő BE ] énytJóvál 


2 S MEZEZSS Sza 


Kereskedelmi menedzser me 


Kedvezménytlöröl 


Use case-ek finomítása 

A rendszer funkcionalitásának teljes mélységű feltárása, megértése érdeké- 
ben a Kereskedő aktor által kezdeményezett use case-ek közül az Ügyfél- 
Tötzsadatotkezel use case-t tovább kell részletezni. A finomítás eredmé- 
nyeként egy alsóbb szinten az ÜgyfélTötzsadatotFelvisz, ÜgyfélTörzsada- 
totKarbantart use case-eket definiáltuk. 
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ÜgyfélTörzsadatotKezel 


aa.  , HB 
ÜgyfélTörzsadatotFelvisz UÜgyfélTörzsadatot 
Karbantart 











Az ÜgyfélTötzsadatotkKezel use case esetén végrehajtott finomításhoz 
hasonlóan az ÁrajánlatotKezel use case-t is tovább kell részletezni. A le- 
képezés eredményeként az ÁrajánlatotkKészít, az ÁrajánlatotMódosít, az 
ÁtajánlatotNyomtat és az ÁrajánlatbólRendeléstVégez use case-ek specifi- 
kálhatók. 











ÁrajánlatotKezel 


vm ván SE 
ae sa SES ae 
ÁrajánlatotkKészít  ÁrajánlatotMódosít  ÁrajánlatotNyomtat 


s 


ÁrajánlatbólRendelést 
Végez 











Az ÜgyfélTörzsadatotkKezel és az ÁrajánlatotKezel use case-eket a finomí- 
táskor csomag elemként specifikáltuk. 


Felhasználói követelmények megvalósítása use case-ekkel 
A követelményspecifikáció első szakaszában meghatároztuk a felhasználói 
követelményeket. A use case modell finomítása során a felhasználói köve- 
telményeket egy vagy több use case valósítja meg. Tekintsünk feladatunk- 
ból egy konkrét példát! 

Az árajánlat kezelési szolgáltatásta vonatkozó felhasználói követelmé- 
nyeket az alábbi módon definiáltuk (lásd 41. oldal: 


e Az ügyfelek kérhetnek árajánlatot a cég ügyfélszolgálatánál, de igénybe 
vehetik az internetes árajánlat szolgáltatást is. 
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Az árajánlat szolgáltatásra vonatkozó felhasználói követelményeket a mo- 


dellben: 


e az Árajánlatotkészít, 

e az Áraj ánlatotMódosít, 

e az ÁrajánlatotNyomtat, 

e az ÁtrajánlatbólRendeléstVégez, 

e az Áraj ánlatotKészít Weben, 

e az ÁrajánlatotLekérdez Weben és 

e az ÁtajánlatotNyomtat Weben use case-ek valósítják meg, implemen- 
tálják. 

A felhasználói követelmények, és az azokat megvalósító use case-ek kö- 

zötti kapcsolatot a függőséggel (dependency) modellezzük. 


Követelmények megvalósítása Enterprise Architect-ben 


ud KövetelményekMegvalósítása 




















7 A felhasználói követelmények, és az azokat megvalósító funkcionális követelményeket 
leíró use case-ek közötti kapcsolatot leíró diagram az Enterprise Architect 5.0 (EA) 
CASE fejlesztőeszközzel készült. Az EA lehetőséget nyújt a követelmények modellezésé- 
re. Az eszköz a követelményeket a diagramban is jól látható négyzetes szimbólummal 
jelöli. 
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Részletes leírás készítése use case-ekhez 

A use case lista összeállítása után minden use case-hez készíteni kell egy 
részletes leírást. Az ÁrajánlatotkKészít Weben use case-hez készített rész- 
letes leírásban négy fotgatókönyvet kell részletezni: 


e A use case normál lefutása szokásos működés esetén: a use case sike- 
tesen véget ér, ha az Ügyfél elfogadja az Arajánlatta vonatkozó feltéte- 
leket. 


A szokásostól eltétő működéskor a lehetséges lefutások, alternatív útvonalak: 


e Az Ügyfél a felhasználói név és a jelszó megadásakot a MÉGSEM 
gombra kattint. 

e Az Ügyfél a felhasználói név és a jelszó megadásakor az OK gombot 
választja, azonban a rendszer a megadott adatok ellenőrzésekor hibát 
talál. A megadott adatok vagy azért hibásak, mert az ügyfél azokat 
rosszul adta meg, vagy azért, mert nem tegisztrált felhasználó. Ilyen 
esetben a use case véget ér. 

e Az Ügyfél a rendszer által küldött Árajánlat elfogadása üzenet megető- 
sítésekot a MÉGSEM gombot választja. 


Forgatókönyv a normál működés leírására 

e Az Ügyfél a cég honlapján aktiválja az , Árajánlat-készítés"? funkciót. 

e A rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél 
felhasználói nevét, és jelszavát. 

e Az Ügyfél megadja a felhasználói nevét, és jelszavát. 

e A rendszer ellenőrzi (validálja) a megadott adatokat. Hibás adatok ese- 
tén újra kéri az adatokat. 

e A rendszer megjeleníti az , Árajánlat-készítés?" felületet. 

e Az Ügyfél megadja a kért adatokat. 

e A rendszert validálja a megadott adatok helyességét, ellenőrzi az adatok 
konzisztenciáját. Ha az Ugyfélnek nem sikerült érvényesen kitölteni a 
lapot, a rendszer mindaddig visszatért a laphoz, amíg azt az Ügyfél he- 
lyesen ki nem tölti. 

e A rendszet megerősítést kér az Ügyféltől az Árajánlat elfogadására. 

e A rendszer elmenti az Árajánlat adatait, és nyugtázó üzenetet küld a 
képetnyőn keresztül az Ugyfélnek az Arajánlat készítésének sikeressé- 
géről. 
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A forgatókönyv készítésekor ellenőriztük, hogy: 


e A use case akkor kezdődik, amikor a cég honlapján az Ügyfél aktiválja 
az , Árajánlat-készítés?" funkciót. 

e A use case sikeresen véget ér, ha az Ügyfél elfogadja az Árajánlatta 
vonatkozó feltételeket, a tendszer elmenti az adatbázisba az Árajánlat 
adatait. 

e Az Ügyfél és a rendszer között kölcsönhatások történnek akkor, ami- 
kor például az Ügyfél a felhasználó név és a jelszó megadása után 
megnyomja az OK gombot. Helyes felhasználó név és jelszó megadása 
esetén a rendszet megjeleníti az , Átajánlat-készítés?" felületet. 

e Adatok cserélődnek a szoftvertendszer és az Ügyfél között akkor, 
amikor például az Ügyfél megadja a felhasználói nevét és jelszavát, 
vagy akkor, amikor az Árajánlat készítésekot az Ügyfél megadja az 
adatokat. 

e A szoftvettendszet mindaddig kéri a felhasználó nevet és jelszót, va- 
lamint az Árajánlat készítési lapon szereplő adatokat, amíg azok kon- 
zisztencia és validitási szempontból nem helyesek. 





A forgatókönyv a use case egy konkrét végrehajtásának lépéseit mutatja 
be. A fotgatókönyvben meghatározott lépéseket az UML-ben tevékenysé- 
geknek, aktivitásoknak nevezzük. A forgatókönyv tehát a tevékenységek 
sorozatát ítja le szöveges formában. A fotgatókönyvben meghatározott 
tevékenységek menetének grafikus szemléltetéséte az UML diagramok 
közül az a£kzíivitási (tevékenységi) diagramot használjuk. Egy use case-hez any- 
nyi aktivitási diagram" készül, amennyi a forgatókönyvek száma. Gyaktan 
azonban az alternatív végrehajtásokhoz tartozó forgatókönyveket — 
amennyiben nem bonyolítja az aktivitási diagramot — egy közös aktivitási 
diagrammal írunk le. 

A fotgatókönyveknek aktivitási diagramokkal való szemléltetése azétt 
célszerű, mett grafikusan áttekinthetőbbé teszi, hogy mi történik, milyen 
tevékenységek zajlanak le a use case végrehajtásakor. 

Az aktivitási diagram egy kezdő- és egy vagy több végpontot tattalmaz. 
A use case végrehajtási menetében az elágazási/döntési (őrfeltétel) pontok- 
tól függően több végpont is lehetséges. A gyakotlatban a diagram készíté- 





8 Az aktivitási diagramokat a 8. fejezet ismetteti. 
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sekor csak egy végpontot célszerű feltüntetni. A kezdő és végpontok mel- 
lett a diagram felsorakoztatja az aktivitásokat (tevékenységeket), grafikusan 
kiemeli az elágazásokat jelölő döntési pontokat, a szinkronizációs vonallal 
elkülöníti a párhuzamosan, az azonos időben zajló tevékenységeket. 





Aktivitási diagram készítése use case-hez 


Az ÁrajánlatotKészít Weben use case-ben definiált működés normál vég- 
rehajtását leíró fotgatókönyv alapján készítsük el az UML aktivitási diag- 
ramot! 


/ Az Ügyfél a Kft. honlapján aktiválja 5 


G az "Árajánlat készítés" funkciót. )) 








V 
/" Arendszer megjeleníti a Login dialógusablakot, — 9 
( ahol kéri az Ügyfél felhasználói nevét, és jelszavát. 9) 





ft Az Ügyfél megadja a b 
X , felhasználói nevét, és jelszavát. — A 








ÜT Arendszer ellenőrzi, validálja 0 
8 a megadott adatokat. [/ 
[ Hibás adatok! 1 





S 


[Adatok rendben! 17 
48 A rendszer megjeleníti az Ha 
he Act eza e TANEEn 








vV 
/" Az Ügyfél megadja a 283 
C. kértadatokat. 7 











f Arendszer validálja a megadott adatok b 


c helyességét, ellenőrzi az adatok konzisztenciáját. . / 
[ Hibás adatok! 1] 








aj 


[Adatok rendben! 1 1 


Ű Arendszer megerősítést kér az 9 
Lk Ügyféltől az Árajánlat elfogadására. / 











13 [ Árajánlat Elutasítva! ] . 
LÁrajánlat rendben! 1 
Dee ÉSE] 











/ Arendszer elmenti az 0V Arendszer nyugtázó üzenetet küld az Ügyfélnek a b. 
( Árajánlat adatait. / ő képernyőn az Árajánlat készítésének sikerességéről. j 
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Aktivitási diagram úszópályákkal (swimlane-ekkel) kiegészítve 


Szereplő:Ügyfél Rendszer 
Árajánlat készíés megkezdése 


[Hibás adatok!) 


[Hibás adatok!) 


(elutasítva) 


Árajánlat készíés befejezése 
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3.2.3. Kapcsolatok 


A use case modell harmadik építőeleme a kapcsolat. Kapcsolaz alatt klasszi- 
kus éttelemben az aktorok és a use case-ek közötti kapcsolatokat értjük. 
Az UML-ben a tendszet szereplői és a use case-ek között definiált kapcso- 
latok modellezéséte a use case diagtam szolgál. A kapcsolatot a diagram- 
ban az aktotokat és a use case-eket összekötő vonal szimbolizálja. A vonal 
lehet irányított. 


Aktotok és use case-ek között értelmezett kapcsolatok típusa 


A korábbi alfejezetekben tátgyaltuk, hogy egy use case-t aktor kezdemé- 
nyezhet, aktivizálhat. A rendszert szereplői és a use case-ek közötti kapcso- 
latot egy nyíl jelöli, mint ahogy azt a 3.5. ábra use case diagramja illusztrál- 
Ja. Az irányítás nem a kommunikáció itányát mutatja, hanem azt, hogy 
melyik aktor kezdeményezi az adott use case végrehajtását. 

Az aktot és a számítógépes rendszet között alapértelmezésben kom- 
munikációs jellegű kapcsolat van, a kommunikatív jelleget a kapcsolatot 
szimbolizáló nyíl felett CCcommunicatez5 sztereotípiával jelölhetjük. A 
gyakorlatban azonban a szteteotípiát nem szokás külön kiírni a kapcsolat 
típusának klasszikus volta miatt. 





42 PT 
Kezdeményező use case 
szereplő 


3.5. ábra. Kapcsolat ábrázolása kezdeményezés esetén 


Egy feladat (use case) végrehajtásában több aktor is közteműködhet (lásd 
3.6. ábra). A use case megvalósításában részt vevő szeteplőket és a use 
case-t egyszetű (irányítás nélküli) vonal köti össze. 

A use case diagramban az aktorok és a use case-ek között definiált 
klasszikus tátrsítási kapcsolatok mellett léteznek ún. speciális kapcsolatok. 
Értelmezünk két aktor közötti kapcsolatot. Definiálhatunk use case-ek 
közötti speciális viszonyokat is. 
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5 
ző VEVv Ő 
e szereplői 


4A—— e 


Kezdeményező use case Ha i 
szereplő 
szereplő2 


3.6. ábra. Kapcsolat szemléltetése közreműködés esetén 


Speciális kapcsolat két aktor között 

Két aktor öröklődési viszonyban állhat egymással. Öröklődési kapcsolat 
akkor jöhet létre, ha egy use case végrehajtásakor több szereplő is betölti 
ugyanazt a szerepet. Az öröklődési viszonyban két aktotrtípust különbözte- 
tünk meg, az egyik a leszármazott, a másik az ős szereplő. A leszátmazott 
minden use case-zel kapcsolatban van, amivel az ős szereplő kezdeményez 
kapcsolatot. Az ős szereplőnél definiált minden use case végrehajtását 
kezdeményezheti, de annál akár többet is. Az aktorok között éttelmezett 
öröklődési viszony UML-ben történő grafikus leírását a 3.7. ábra szemlél- 
tett. 


5 e 


Ős szereplő use case/funkció 
oO oO 
He 
Leszármazott Leszármazott 
szereplői szereplő2 


3.7. ábra. Öröklődési viszony aktorok között 


Speciális kapcsolatok use case-ek között 


A use case-ek között három speciális viszonyt értelmezünk. Megkülönböz- 
tetünk tattalmazást, kiterjesztést és öröklődést. 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 61b 


Az UML Nyelv használata Use case modellezés 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza d 62 b 


Tartalmazás —- include viszony 


e A szereplő által kezdeményezett (alap vagy normál) use case-ek végre- 
hajtásában vannak olyan részek, lépések, amelyek mindegyik use case 
végrehajtásakor bekövetkeznek és azonos módon játszódnak le. Ér- 
demes az azonos viselkedéseket egy külön use case-be kiemelni. A ki- 
emelt viselkedést tartalmazott vagy rész use case-nek hívjuk. A tartal- 
mazott elnevezés utal arra, hogy a tartalmazott use case az alap use 
case-nek szerves része. A tartalmazott use case végrehajtása feltétel 
nélküli, vagyis az alap use case végrehajtáskor mindig bekövetkezik, le- 
játszódik. 

e Az UML-ben az alap use case-t és a tartalmazott use case-t szaggatott 
nyíl köti össze. 

e A szaggatott nyíl az alap use case-től a tartalmazott felé mutat. 

e A kapcsolat tartalmazás jellegét a szaggatott nyílon elhelyezett, francia 
zárójelek közé ítt c Czuchude22 sztereotípiával jelöljük. A leendő tendszer 
fejlesztése sotán definiált use case-ek között értelmezett tartalmazás 
viszonyt a 3.8. ábra use case diagramja illusztrálja. 


ez ccaincudeszz 
él. (7 alapfnormáluse caset 
ÉL sad 7 Mé. 288 
Etzel 


3.8. ábra. Include kapcsolat use case-ek között 


Kiterjesztés — extend viszony 


e A modellben lehetnek use case-ek, amelyek végrehajtási menetében 
bizonyos feltételek bekövetkezésekor a vezétlés egy másik use case- 
nek adódik át. Ilyenkor a normál use case-nek egy bővített változata 
játszódik le. Mivel a normál use case viselkedésében a feltétel csak bi- 
zonyos esetekben következik be, ezért a normál use case-t bővítő vi- 
selkedést érdemes külön use case-ben leírni. 

e A feltételt a követelmények specifikálásakor kell megadni. 
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Az UML-ben az alap use case-t és a kiterjesztett use case-t szaggatott 
nyíl köti össze. 

A szaggatott nyíl a kitetjesztett use case-től az alap use case felé mutat. 
Az extend viszonyt a szaggatott nyílon elhelyezett, ftancia zárójelek 
közé írt CZextend22 sztereotípiával adjuk meg. A normál use case vég- 
rehajtása során a normál use case végrehajtási menetében definiált fel- 
tétel teljesülésekor bekövetkező vezérlésátadás UML szetinti grafikus 
leírását a 3.9. ábra use case diagramja szemléleti. 


j EZT ccextendss PF ES 
k— 2 
Aktor alap/normál use case kiterjesztett (extended) 
use case 





3.9. ábra. Az extend kapcsolat 


Öröklődés — generalizáció 


Az öröklődési viszony esetén a leszármazott use case örökli a normál 
use case viselkedését, kapcsolatait. A leszármazott az eredeti/normál 
use case viselkedéséhez hozzáadhat újabb viselkedéseket, sőt az eredeti 
use case viselkedését felülbírálhatja, felülírhatja. 

Az ötöklődést az UML-ben egy telt fejű nyíl jelöl. A nyíl a leszárma- 
zott use case-től az általánosított normál (ős) use case felé mutat. Use 
case-ek között értelmezett öröklődési viszony grafikus megjelenítését a 
3.10. ábra use case diagramja illusztrálja. 


Pe. a 


Aktor leszármazott use case 





3.10. ábra. Öröklődési viszony use case-ek között 


A speciális kapcsolatokkal a rendszerünkben zajló folyamatokat tudjuk 
még pontosabban modellezni. Az CCincludezz minősítést azoknál a 


funkcióknál használjuk, amelyek végrehajtási menetében közös tevékeny- 


ségek azonosíthatók. Az CZincludez5 sztereotípia megadásával a közös 


viselkedést a rendszerben csak egyszer kell modellezni. A gyakorlatban az 


CZincludezz sztereotípiát általában hibaesemények kezelésének, a fel- 
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használói visszalépéseknek, megszakításoknak és egyéb különleges részte- 
vékenység sorozatoknak a leírására használjuk. 

A use case-ek között értelmezett CZincludez3 és CZextends5 kap- 
csolatok modellezésekor az általánosítás irányának jelölése ellentétes. A 
nyíl az általánosabb viselkedésű modellelemtől a specializáltabb felé mutat. 
Az ábtázolásnak ez a módja logikus, hiszen C Cextend55 viszony esetén a 
bővített use case az általánosabb, CCincludez3 esetén pedig a normál 
use. 





Use case modell készítése, strukturálása 


A use case modell strukturálása sotán a modellben azonosított speciális 
kapcsolatok az alábbiak: 


e A Kereskedelmi menedzser rendelkezik mindazokkal a jogokkal, ami- 
vel a Kereskedő munkatárs. Ez a modellben azt jelenti, hogy a Keres- 
kedelmi menedzser a Keteskedő összes kapcsolatát örökli. A Kereske- 
dő által elindított összes use case-t kezdeményezheti, sőt további fel- 
adatokat (KedvezménytJóváhagy, ill. KedvezménytTöröl use case-ek) 
is végrehajthat. 


2 ú 
ag 
e 9 
Kereskedő Kereskerkltei 
menedzser 


e A megrendelések (MegrendeléstkKezel use case) összeállításakor a 
rendszer nagyvásárlók esetén ellenőrzi, hogy az Ügyfél három korábbi 
megrendelését pénzügyileg teljesítette-e. Abban az esetben, ha pénz- 
ügyi teljesítésekre vonatkozó feltétel nem teljesül, (Extention Point) a 
tendszet nem engedi rögzíteni az újabb megrendelést. A vezérlés a 
Kedvezmény zárolása use case-nek adódik át, aminek végrehajtása so- 
tán figyelmeztetés megy a Kereskedelmi menedzser-nek, aki tötli az 
Ügyfélnek adott törzsvásátlói kedvezményt (KedvezménytTöröl use 
case). A KedvezménytZárol use case normál esetben (ha a feltételek: 
nagyvásátló-t-pénzügyi teljesülnek) nem játszódik le, csak akkor, ha a 
feltételek (az Ügyfél nagyvásárló és az Ügyfél három korábbi megren- 
delését pénzügyileg nem teljesítette) teljesülnek. 
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A 


Kereskedő 








da a 


MegrendeléstKezel Kedvezménytzárol 


e Interneten az ügyfelek árajánlatot csak akkor készíthetnek, vagy a meg- 
levő ajánlataikat csak akkor kérdezhetik le, ha regisztrált ügyfelek a 
tendszetben. Ez azt jelenti, hogy minden alkalommal, új árajánlat felvi- 
telekor, lekérdezésekor azonosítani kell magukat a regisztráció (Re- 
gisztrál use case) során megadott helyes felhasználói névvel és jelszó- 
val. Az ügyfél-azonosítás az ÁrajánlatotkKészít Weben, az Árajánlatot- 
Lekérdez Weben use case-ek végrehajtásakor azonos módon játszódik 
le, ezért ezt érdemes kiemelni egy külön use case-be (ÜgyfeletAzono- 
sít felhasználó névéeJelszó use case). 

a 


7 Árajánlatotkészít — CSindudez: 


(65 MESE Et . Weben ag 
A SEN a 
5 pe ccindudezz " "  ÜgyfeletaAzonosít 
Ugyfél STT felhasználóinévgzJelszó 
fd az Aa 
ÁrajánlatotLekérdez 
. Weben 


e — Az ÜgyfélTötzsadatotKatbantart use case örökli az ÜgyfélTörzsada- 
totFelvisz use case viselkedését. Az ÜgyfélTötzsadatotFelvisz use case 
végrehajtása új ügyfelet tögzít a tendszerben. Az ÜgyfélTötzsadatot- 
Katbantatt use case végrehajtása az ügyféladatok rögzítése mellett még 
biztosítja az ügyféladatok lekérdezését és módosítását. Módosítás ese- 
tén a korábban rögzített és módosított ügyféladatok felülítódnak. 


5 d 
17 Sz 





ÜgyfélTörzsadatotFelvisz 
Kereskedő A 
A 
ccgeneralizations 2 

zzz 

sé 

ÜgyfélTörzsadatot 
Karbantart 
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3.2.4. Use case diagram 


A követelményspecifikációban feltárt use case-eket, szereplőket és a kö- 
zöttük értelmezett kapcsolatokat wse case diagramban ábrázoljuk. A diagram 
segíti a rendszer viselkedésének megértését és grafikus modellezését. A 
fejlesztendő tendszerrel kapcsolatban elkészített use case diagramok al- 
kalmasak a tervezett tendszettel szemben támasztott követelmények (use 
case-ek halmaza) meghatározására, leírására. A diagram szemléletes, köny- 
nyen áttekinthető, logikája könnyen érthető, emiatt nemcsak a fejlesztők 
által végzett követelményelemzést könnyíti meg, de hatékony eszköz a 
felhasználókkal történő kommunikáció megkönnyítésére. 





Use case modell 


Az ügyféladatok, az árajánlatok és a megrendelések (vásárlások) kezelését 
modellező use case diagram részletet az alábbi ábra szemlélteti. 
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Számlázó rendszer 


Az Ügyfél által kezdeményezett use case-eket összefoglaló use case diag- 
tamot a következő ábra foglalja össze. 
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3.3. A use case modell dokumentálása 


A use case modellezés során fontos a különböző modellelemek megfelelő 
dokumentálása. Minden elemhez készíteni kell szöveges specifikációt, 
leírást, szükség esetén a még jobb megértés étdekében részletesebb ma- 
gyatázó kiegészítést kell adni. 

A use case modell dokumentálásának menete: 


e — Aktorok azonosítása. 
e Minden aktor esetén meg kell határozni, hogy mit vár el a rendszertől. 
e Use case-ek feltárása, use case lista összeállítása. 
e — Minden use case-hez részletes leírás készítése: 
— Alternatív forgatókönyvek készítése a use case működésének leírá- 
sára. 
—  Aktivitási/tevékenységi diagram készítése. 
e Kapcsolatok meghatározása: 
— Kapcsolatok aktor és use case között. 
— Speciális kapcsolatok azonosítása. 
e A rendszer funkcionalitásának, viselkedésének grafikus modellezése 
use case diagramok készítésével. 
e A fejlesztés sotán menetközben módosult funkciók dokumentálása, az 
elfogadott módosítások átvezetése a követelménydokumentumba. 
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3.4. Use case realizáció - a use case-ek 
megvalósítása 

A követelménymodellben a use case-ek viselkedésének vizsgálatakor csak 

a felhasználó és a szoftvertendszer közötti interakciók pontos leítására 

koncenttráltunk. Az új tendszett kívülről vizsgáltuk, elemeztük, a MIT-re, a 

tendszer által megkövetelt szolgáltatások megfogalmazására helyeztük a 

hangsúlyt, nem tértünk ki a megvalósítás részleteire,a HOGYAN -ra. 

A use case modellben definiált use case-eket az elemzési, majd a terve- 
zési modellben tovább elemezzük, részletezzük. Ezekben a fejlesztési 
munkaszaka-szokban a rendszer belsejét tértképezzük fel. Azt vizsgáljuk, 
hogyan lesznek a rendszertől elvárt funkciók, use case-ek megvalósítva, 
majd implementálva. Ennek a munkának egy fontos lépése, hogy a use 
case modellben definiált minden use case-hez el kell készíteni annak meg- 
valósítását specifikáló use case realizációt (use case trealization). 

Minden use case-hez definiálhatunk az elemzési modellben egy use 
case realizációt. A wse case realizáció a use case egy lefutásának részletes le- 
írása a tendszetren belül. A use case realizáció a modellben egy olyan use 
case lesz, aminek a sztereotípiája CCuse case realization— 5. A modellben 
a use case tealizációt szaggatott vonalú ellipszis szimbolizálja (lásd 3.11. 


ábra). 


use case realization 
3.11. ábra. A Use Case Realization UML szimbóluma 


A követelménymodellben definiált use case és az elemzési modellben en- 
nek megvalósítására szolgáló use case realizáció között függőségi viszonyt 
értelmezünk. Az asszociációnál erősebb megszorítású függőségi viszony- 
nyal azt fejezzük ki, hogy a use case megvalósítása a követelménymodell- 
ben meghatározott use case viselkedésétől függ. A követelménymodellben 
meghatározott use case viselkedésében bekövetkezett változás kihat a 
megvalósításra, módosítja az implementációt. A két elem között éttelme- 
zett függőségi kapcsolat felett a CCttaces5 sztereotípia megadásával jelöl- 
jük, hogy az irányítatlan végén szereplő modellelem a másik modellelem 
megvalósítása (lásd 3.12. ábra). 
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db zatraceszz 


use case use case realization 


3.12. ábra. Use case megvalósítása függőségi viszonnyal 


A use case realizáció modellezésére az UML diagramok közül az ese- 
ménykövetési (szekvencia) diagramot használjuk. A diagtam tartalmazza a 
működéshez szükséges objektumokat és az objektumok közötti üzenetvál- 
tásokat, azok időbeli sorrendjében. A use case-ben leírt működést a tend- 
szerben definiált objektumok valósítják meg, mely objektumok egymással 
üzenetváltásokkal kommunikálnak. A use case funkciója az üzeneteken 
keresztül teljesül. Az üzenetek eljárás vagy függvény jellegűek lehetnek, ez 
utóbbiak visszatérési értékét is megadhatjuk. Az üzenetek paraméterez- 
hetők. 

Az elemzési szakaszban a use case egy részletes lefutását leíró ese- 
ménykövetési diagramot a tervezési modellben tovább tészletezzük. Ha- 
bár a különböző munkaszakaszokban elkészített eseménykövetési diagra- 
mok mindegyike az eredeti use case-ben leírt működést írja le, azonban a 
tetvezés során készített modellek tovább részletezik az elemzési modell- 
ben leírt működést a kiválasztott implementációs környezetben megvaló- 
sítható objektumok, ill. osztályok definiálásával és a köztük megvalósuló 
üzenetváltások leírásával. Az elemzési modellben nagyvonalakban definiált 
szoftverarchitektúra végleges formája a tervezési fázisban alakul ki. A ter- 
vezési szakaszban pontosan definiálni kell a leendő tendszer felépítését, 
egyértelműen elhatárolva egymástól a rétegeket (üzleti logika réteg, alkal- 
mazási téteg, adatbázis réteg stb.), és a tétegekbe tattozó objektumokat. 





Use case trelaizáció készítése 


Az ÁrajánlatotKészít Weben use case lefutását a rendszeren belül az 
ArajánlatotKészít Weben use case tealization valósítja meg. 


szál catracesz 

ke 
ÁrajánlatotKészít ÁrajánlatotKészít Weben 

. Weben realization 
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Eseménykövetési diagram készítése az elemzési munkaszakaszban 


Az ÁrajánlatotKészít Weben use case realizációt az eseménykövetési di- 
agtammal írjuk le. A diagram az UML 1.5-ös szabvány alapján készült. A 
diagramon ábrázoljuk a működésben megjelenő objektumokat és az ob- 
jektumok közötti üzenetváltásokat, azok időbeli sottendjében. Az elemzési 
szakaszban a use case realizációt leíró eseménykövetési diagram még nem 
olyan tészletes, mint a tetvezési modellben készített eseménykövetési diag- 
tam. Az eseménykövetési diagram (szekvenciadiagram) leírása az 5.2. al- 
pontban található. 
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Eseménykövetési diagram készítése a tervezési szakaszban 
A diagram készítésekor az UML 2.0 szabvány leítását követtük. 
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A szoftverfejlesztési folyamatban a követelmények összegyűjtése, elemzé- 
se és változásaik nyomon követése fontos feladat. Az ellenőrzési munka 
során azt kell megvizsgálni, hogy a követelmények, a követelményeket 
leíró modellek (use case modellek), dokumentációk (pl. fogalomszótár) 
stb. minden szempontból megfelelnek-e a felhasználó elvárásainak. Az 
ellenőrzési feladatok végrehajtását review-k (értékelő áttekintés) készítése 
vagy ptototípusok készítése segíthetik. 

A követelményspecifikációban az ellenőrzési munkának ki kell terjedni 
a teljes követelményhalmaztra. A rendszert leíró követelményhalmaznak: 


e Minden szempontból teljesnek kell lenni, azaz tartalmazni kell minden 
szolgáltatás pontos leírását, az ehhez szükséges információkat. 

e  Konzisztensnek kell lenni, vagyis a rendszer leírásban, a szolgáltatások 
definícióiban, a felállított modellekben nem lehetnek ellentmondások. 

e — Hibamentesnek kell lenni. 


A tendszerre vonatkozó követelményhalmaz mellett ki kell térni a köve- 
telmények egyedi vizsgálatára. Étdemes számba venni, hogy a vizsgálat 
tárgyát képező követelmény étthető-e, jól definiált, tesztelhető-e, ismert-e 
a fottása, megvalósítása esetleg sért-e valamilyen szakterületi követel- 
ményt. 

A követelmények ellenőrzése, az ellenőrzési munka eredményeként a 
változtatások végrehajtása, a javítások elvégzése elengedhetetlenül szüksé- 
ges a további fejlesztési feladatok felhasználói igényeknek megfelelő vég- 
trehajtásához. 
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4. Osztályok, objektumok, 
osztálydiagram 


Az osztálydiagtam a legismertebb objektumortientált (OO) modellezési 
technika. Az 00-módszettanok legalapvetőbb eszköze, a rendszer objek- 
tumait leíró osztályokat és a közöttük levő kapcsolatokat modellezi. 

A fejlesztés különböző munkaszakaszaiban készülnek osztálydiagra- 
mok. Ez nem újabb és újabb modellek megalkotását jelenti, a fejlesztés 
teljes ideje alatt egy alapmodellt vizsgálunk. Ezt az egy modellt fokozato- 
san bővítjük a megfelelő részletekkel a fejlesztés menetében előrehaladva. 
A modell aktuális állapotát, érettségét az egyes szakaszokban készített osz- 
tálydiagramokkal ábrázoljuk. 


4.1. Osztálydiagramok használata a fejlesztés 
különböző szakaszaiban 


Az osztálydiagramokat a fejlesztés különböző szakaszaiban más és más cél- 
lal definiáljuk és használjuk, ennek megfelelően azok értelmezése is eltérő. 


4.1.1. Osztálydiagramok az üzleti modellezésben 


Az üzleti modellezés során készített ún. szakterületi osztálymodel/ a szaktetület 
valós elemeit ábrázolja, amelyek meghatározó szerepet játszanak a vizsgá- 
lat tárgyát képező szetvezet, szakterület működésében, a probléma megér- 
tésében. A modell célja az elemek fogalmi szintte emelése, a közöttük 
értelmezett kapcsolatok és szerepeik meghatározása. A szakterületi osz- 
tálymodell elemei az üzleti aktorok és üzleti entitás jellegű objektumok. A 
szakterületi osztálymodell elkészítésének alapja az üzleti folyamatmodet! (Bu- 
siness Process Model), a folyamatmodellezés során meghatározott üzleti use 
case-ek, és a use case-ek megvalósításában tészt vevő üzleti szerep- 
lők/aktorok (szetepkörök) és entitások. A szakterületi osztálymodellezés 
sotán azonosított üzleti entitásobjektumokat, az objektumok közötti kap- 
csolatokat az özleti objektummodellben (Business Object Model) foglaljuk össze. 
Az üzleti modellek (szakterületi osztálymodell, üzleti objektum modelh 
és a követelményspecifikációban felállított use case modell az alapja, beme- 
nete az elemzés/ tervezés" során fokozatosan bővített osztálymodelleknek. 





) A RUP az elemzést és a tetvezést nem önálló munkafolyamatként definiálja, azokat a 
kétdimenziós modellben egy munkaszakaszként értelmezi. 
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4.1.2. Osztálydiagramok az elemzési munkaszakaszban 


Az elemzés kezdeti szakaszában a szekvenciadiagramok segítségével feltárjuk 
a use case-ek működéséhez (use case tealization) szükséges objektumokat, 
meghatározzuk az objektumok között zajló üzenetváltásokat. Az objek- 
tumok kapcsolati viszonyait, a kapcsolatokban játszott szetepeket az 
együttműködési (collaboration) diagramban ábrázoljuk. Az együttműködési diag- 
tam, amelyet a gyakorlatban objektumdiagtamnak is neveznek, csak a use 
case működésében azonosított objektumokat, a kapcsolatokat, szetepeket 
és az objektumok kapcsolódásának számosságát képes leírni. A szekven- 
ciadiagramok és az együttműködési diagramok segítségével feltárt objek- 
tumokat leító osztályok, adataik (attribútumok), műveleteik és kapcsolataik 
közvetlen forrásként, bemenetként szolgálnak a fejlesztendő szoftvetral- 
kalmazás elemzési osztály-modelljének elkészítéséhez. 

Az elemzési osztálymodell az elemzés során feltárt új elemek mellett 
tattalmazza az üzleti objektum modellben specifikált azon elemeket is, 
amelyek a tervezett szoftvertendszer működéséhez szükségesek". Az üzle- 
ti modellezés során felállított üzleti objektum modell nem más, mint az 
elemzési osztály-modell egy speciális, más megközelítésben értelmezett 
formája. Az üzleti objektummodell a szakterület objektumai alapján általá- 
nosított kategóriákat, és azok kapcsolatait ábrázolja. Az itt azonosított 
objektumokat részletezzük, újabb jellemzőkkel bővítjük az elemzési osz- 
tálymodellben a szekvencia és az együttműködési diagramok segítségével. 


4.1.3. Osztálydiagramok a tervezési szakaszban 


Az elemzési osztálymodellt az elemzés/tervezés során továbbbővítjük, 
fejlesztjük. Részletezzük az osztályokat, pontosan deklaráljuk az attribú- 
tumokat, műveleteket, értelmezzük a kapcsolatokat, azonosítjuk a speciális 
asszociációs viszonyokat. A fenti műveletek eredményeként áll elő a 
szoftveralkalmazás részletes osztálymodellje, amely a kódolás alapja. A 
szakirodalom ezt a modellt tervezési osztálymodellként azonosítja. 


4.1.4. Az osztálydiagramok jelölésrendszere, perspektívák 


A fejlesztés különböző szakaszaiban (üzleti modellezés, elemzés, tervezés) 
készített  osztálydiagramok jelöléstendszerükben számos hasonlóságot 
mutatnak. Az osztályok és az osztályok között értelmezett kapcsolatok 
ábrázolására az UML nyelv szimbólumait használjuk. Az osztálydiagramok 





10 Az üzleti modellben definiált üzleti modellelemek nem mindegyike szerepel az elemzési 
modellben, csak azok, amelyek a működést meghatározzák. 
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céljukban, tartalmukban különböznek, az eltérő munkaszakaszokban felál- 
lított osztálymodellekkel mást akarunk leírni, mást hangsúlyozunk. A fej- 
lesztés kezdetén főként atta van szükség, hogy csak a probléma megérté- 
séhez szükséges lényegi elemeket és azok kapcsolatait modellezzük, nem 
törődve azok megvalósításával. 

Az elemzési szakasz végén — amikot a probléma már világos, és min- 
den követelményt részletesen elemeztünk és definiáltunk — hasznos készí- 
teni egy összefoglaló osztálydiagramot, amelyik részletesebb. Ez a modell 
már szoftverkomponenseket, interfész specifikációkat tartalmaz, de nincs 
elkötelezve egyik programnyelvi környezetnek sem. 

A tetvezési fázis végén rendelkezésre kell állni annak az osztálymo- 
dellnek, amelyik már pontosan egy bizonyos programfejlesztési környe- 
zethez kötődik (például a kódolás a Java programfejlesztői környezetben 
történik). 

A fenti gondolatmenetre alapozva számos módszettan az osztálydiag- 
tamok három alapvető petspektíváját különbözteti meg, amelyekhez az 
osztálydiagramok modellelemeinek három különböző értelmezése kapcso- 
lódik. Bár ez nem tésze az UML definíciójának, de hasznos abban az étte- 
lemben, hogy mindig csak az aktuális probléma megoldására engedi a fej- 
lesztésben tésztvevő szakembereket koncentrálni. 


e — Konceptnuális (lényegi — concebínal) perspektíva: Ezek az osztálymodellek segí- 
tenek a probléma megértésben, a kommunikációban. A konceptuális 
modell csak a lényegi elemekte, az elemek közötti kapcsolatok leírására 
koncentrál. A diagramban ábrázolhatjuk a kapcsolat fokát, megadhat- 
juk az asszociáció nevét, a különféle asszociációs viszonyokat, mint 
öröklődés, aggtegáció, kompozíció. A lényegi elemek megtalálásnak 
egyik hatékony módszere, amikor a felhasználóval folyatott megbeszé- 
léseket rögzítő dokumentumokban megkeressük a főneveket. A mo- 
dell készítésekor nem vesszük figyelembe azt a szoftvert, amelyik majd 
ezeket az elemeket implementálja. 

e  Specifikációs (specification) perspektíva: Átmenet a konceptuális és az imp- 
lementációs megközelítés között. Az osztálymodellek ezen típusa már 
a fejlesztendő szoftvette koncentrál. A use case-ek fizikai megvalósítá- 
sának módját írja le, a megvalósítás vázát adja. A modellelemekhez fe- 
lelősségeket határoz meg, de ezt nem kód szinten teszi. A specifikációs 
modell az alkalmazás struktúrájára, felépítéséte összpontosít. A fejlesz- 
tendő szoftver funkcionalitását tekintve bonyolult, elsőként célszerű 
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azt logikus részekre bontani. A specifikációs aspektusban készített 
modell a funkcionális felosztás eredményeként keletkezett szoftver- 
komponenseket, azok közötti kapcsolatokat (interfész), a kapcsolódás 
módját hangsúlyozza. Emiatt ebben a megközelítésben nem igazán 
osztályokról, hanem típusokról beszélünk. (egy Order-nek lesz felelős- 
sége, hogy megmondja melyik Customer-ért felelős — az Order és a 
Customer közötti kapcsolatra koncentrál). 

e I/yplementációs (implementation) perspektíva: Ezek az osztálymodellek már 
valódi, a későbbi rendszerben megvalósítandó osztályokat írnak le 
konktét programnyelvi környezetben. 


Az üzleti modellezők főként a valós elemeket leíró konceptuális modellt 
készítenek. Az elemzők, tetvezők szoftverkomponensekre koncentrálnak, 
a fejlesztésnek ebben a szakaszában a kidolgozás részletezettségétől füg- 
gően a specifikációs vagy az implementációs perspektíva érvényesül. 


4.2. Objektum, osztály 


Az olbjekímnmok a valós világ elemeit reprezentálják, modellezik. Például 
ezek a valós elemek a fizikai világban megjelenő konkrét egyedek, diszkrét 
entitások, amik lehetnek személyek, fizikai berendezések, elvont fogalmak 
(pl. kamatláb) stb. Az objektumok a valós elemekhez hasonló jellemzőkkel 
bírnak. Tulajdonságaik vannak, ismert az állapotuk, leítható a viselkedé- 
sük. 


Az objektum állapota 


Az objektumok életük folyamán a környezetükben levő más objektumok- 
kal kapcsolatba kerülhetnek, egymásra hatással lehetnek. Az objektumok 
az őket ért hatásokra adott módon reagálnak, aminek eredményeként kü- 
lönböző állapotokba kerülhetnek. A pillanatnyi állapotot az adott pillanat- 
ban felvett tulajdonságértékek és az objektumnak a környezetében levő 
más objektumokkal megvalósított kapcsolatai határozzák meg. 


Mit takar az objektumok viselkedése? 


Az objektumokat különböző hatások érhetik, másrészt az objektumok 
maguk is hatással lehetnek más objektumokra. Az objektum viselkedése 
nem más, mint az általa végrehajtott tevékenységsorozat, reakció az általa 
előidézett vagy az őt ért hatásra. Az objektumok egymásra üzenetek for- 
májában fejtik ki hatásukat, viselkedésük egyik kifejezési módja a kommu- 
nikáció. Az objektumok önálló, diszkrét entitások, ezért a környezetükkel 
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folytatott kommunikáció csak bizonyos módszetek által alkotott felületen 
keresztül engedhető meg (egységbezárás" fogalma), ezáltal a rendszer 
áttekinthetőbb és könnyebben módosítható lesz. 


4.2.1. Az osztály 


Az objektumok információt tárolnak (tulajdonságaikat leíró attribútumok 
formájában) és kérésre feladatokat ún. metódusokat hajtanak végre. Az 
objektum tehát adatok és metódusok összessége. 

Az objektumokat a modellben az osztály modellelem ítja le. Az oszzályok 
az azonos tulajdonságokkal (attribútumok), viselkedéssel (metódusok) és 
kapcsolatokkal rendelkező objektumok csoportjának, halmazának leírására 
szolgálnak. Az objektum az osztály konkrét megjelenési formája, egyedi 
példánya (instancia). Az osztály tehát attribútumok és metódusok (függvé- 
nyek, eljárások) gyűjteménye, a közös tulajdonságokkal és viselkedéssel 
tendelkező objektumokat írják le. 

A fejlesztési munka végső célja a rendszert felépítő osztályok, és az 
osztályok közötti kapcsolatok feltárása, majd az osztályok fortráskódhoz 
rendelése és kódolása. 

Az osztályt az UML-ben egy három tészre osztott téglalap modellezi 
(lásd 4.1. ábra): 


e az osztály megnevezését a felső részben adjuk meg, 
e a középső tészben találhatók az attribútumok (tulajdonságok), 
e az alsó rész a műveleteket tattalmazza. 





Osztálynév 
EöattribútumNév 


IEműveletNévO 


4.1. ábra. UML osztályszíimbólum 




















11 Egy tetszőleges objektum tulajdonságadatai csak az adott objektum metódusaiban 
láthatók, kívülről más osztály metódusaiból csak azok az elemek éthetők el, amelyeket az 
osztály engedélyez. 
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Az UML-ben a három tészre osztott téglalap alapértelmezésben osztályt 
szimbolizál. Ha az osztály egy konkrét példányát, vagyis pontosan egy 
objektumot akarunk modellezni, annak jelölésére az osztályhoz hasonló 
téglalap szimbólumot kell használni 7. A 4.2. ábra jól illusztrálja, hogy az 
objektumot az osztálytól az különbözteti meg, hogy az objektum neve alá 
van húzva. Lehetőség van csak az objektum nevét megadni az Objek- 
tumNév szintaxissal, vagy a téglalapban az ObjektumNév:OsztályNév 
szintaxissal jelölhetjük azt is, hogy az objektum pontosan melyik osztály- 
hoz tartozik, melyik osztály példánya. 


ObjektumNév ObjektumNév : OsztályNév 


4.2. ábra. Objektumok jelölése 





Az osztálynév megválasztása 


Az osztály elnevezésekor arra kell ügyelni, hogy a választott név tisztán, 
egyedien jellemezze az osztályt. A név adja az osztály identitását. A válasz- 
tott név lehetőleg nagybetűvel kezdődjön, célszerűen egyes számú főnév 
legyen. Ha az osztálynév több szóból áll, célszerű a szavakat nagybetűvel 
kezdeni, vagy aláhúzást használni a szavak között. 


4.2.2. Attribútumok 


Az objektumok meghatátozott tulajdonságokkal, jellemző sajátosságokkal 
ún. attribútumokkal (attribute) tendelkeznek. Az attribútum-érték az attribú- 
tum egy konktét előfordulása, egy adott pillanatban felvett állapot, az ob- 
jektumpéldányban tárolt elemi adat. Az attribútum elnevezésekor a válasz- 
tott név mindig utaljon az általa hordozott infotmációtattalomra. Az attti- 
bútumokhoz az attribútum nevének megadásán túl további információk 
rendelhetők. Az attribútumok specifikációjának általános formája: 


[láthatóság] név [: típus] [7 kezdeti érték] [fjellegi] 


A láthatóság kifejezi, hogy az objektum különböző tulajdonságai, metódu- 
sai mennyire fedhetők fel a külvilág számára. Az UML az osztályjellem- 
zőkhöz (attribútum, művelet) hátom láthatósági szintet javasol: 





12 Az UML-ben az aktivitási, a szekvencia és az együttműködési diagramok mindegyike 
tartalmaz objektumokat. 
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e a public: a jellemző interfészen keresztül tetszőlegesen minden osz- 
tály által elérhető, nincs szükség metódusra az eléréséhez, 

e a — private: csak az osztály látja, csak saját objektumon belül látszik. 

e at protected: a jellemző csak saját objektumból és az utódokból lát- 
szik, csak az adott osztályon érhető el, a gyermek (leszármazott) és a 
barát (friend ") osztályok látják. 


A típus egyszetű adattípusokat jelent. A kezdeti érték az objektum készíté- 
sekor beállítandó értéket jelenti. A jellemzők speciális tulajdonságokat 
mutatnak (pl. frozen). 

Az attribútumok meghatározásakor figyelmesen kell eljárni, mert egyes 
adatok az elemezés/tervezés későbbi szakaszaiban maguk is objektumok- 
nak minősülhetnek (pl. lakcím vagy dátum). Az ilyen attribútumok számá- 
ta a modellben külön osztályt kell definiálni. 


4.2.3. Műveletek 


A művelet (operation) az osztály által nyújtott szolgáltatás. Feladat, tevékenység, 
amit az osztály végte tud hajtani. Az osztályok által nyújtott szolgáltatásokat 
elsősorban eseménykövetési diagramok üzenetei alapján azonosítjuk. 

A művelet megvalósítása a metódus. Egy osztály minden konkrét ob- 
jektuma azonos műveletekkel rendelkezik. A metódusok segítségével vég- 
zünk műveleteket a tulajdonságokon, ill. módosíthatjuk azokat. 

A műveleteket: 


e a művelet jellegének, nevének, 

e a paraméterek nevének és típusának, 

e a visszatérési értékeknek és típusuknak, valamint 

e az alapértelmezett értékeknek a megadásával jellemezzük. 


A műveleteknek két nagy csoportját különíthetjük el. A módosító művele- 
tek azok a műveletek, amik megváltoztatják az adott objektum állapotát, 
ezért végrehajtásukra mindig figyelni kell. A lekérdező műveletek csak 
pataméterétrtéket kétnek más objektumoktól, nem változtatják meg a le- 
kétdezés pillanatában megfigyelt állapotot. Az utóbbiak további jellemző- 
Je, hogy tetszőleges sottendben hajthatók végre. A műveletek ezen két 





15 Egy osztálynak barátja (friend) egy olyan metódus vagy akár teljes osztály, amely hoz- 
záférhet az adott osztály minden — ill. deklarációtól függően néhány — mezőjéhez és 
metódusához. 
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csopottját az UML szintaxis nem különbözteti meg, ezért ezt célszerű 
valamilyen módon a nevükben jelezni. 


.z.z 


[láthatóság] név [(paraméter lista)] [: visszatérési érték típusa] [fjellegi] 


4.2.4. Asszociáció 


Az osztályok szolgáltatásaikat legtöbbször csak más osztályokkal együtt- 
működve tudják biztosítani. Ez a megszorító jellegű állítás azt jelenti, hogy 
az osztályoknak egymással kapcsolatot kell létesíteni, egymással kapcsolat- 
ban kell lenni. 

Az asszociáció (association) az osztályok objektumai közötti kapcsolat le- 
írása, abszttakciója. Az asszociációt, mint viszonyt megtestesítő fogalmat 
az osztályok közötti viszonyokra értjük. A kapcsolat fogalmat az objektu- 
mok közötti viszonyta értelmezzük. 

Az osztályok közötti asszociációs viszonyokat számos paraméterrel jelle- 
mezhetjük: 


e Két osztály vagy osztályok közötti kapcsolatot a két osztályt összekötő 
vonal teprezentálja. 

e Az asszociációhoz név rendelhető: a nevet az osztályokat összekötő vonal 
fölé, középre helyezve írjuk. 

e  Megadhatjuk az osztályoknak az asszociációban játszott szerepét: tmin- 
den kapcsolathoz két szerep rendelhető, amelyek az asszociáció két 
végén levő osztályoknak az adott asszociációban betöltött szerepére 
vonatkoznak. A szerepek definiálásával párhuzamosan általában meg- 
adjuk a kapcsolat (asszociáció) irányát. A szetepeknek az osztályokhoz 
rendelése az atttibútumokhoz hasonló funkciót töltenek be. 

e A kapcsolat fokának megadásával jelölhetjük, hány objektum vehet tészt 
az asszociációban (mudtiplicitás) ": a multiplicitás kifejezi, hogy az egyik 
osztály egy objektumához a másik osztályból hány objektum tattozik, 
vagyis kifejezi, hogy az osztályok objektumai milyen számosságban 
kapcsolódnak egymáshoz. A multiplicitás jelölése az UML-ben: 

1: az adott osztály egy objektumához a másik osztályból pontosan egy 
objektum kapcsolódik 
0..1: 0 vagy 1 objektum kapcsolódik, opcionális kapcsolat 





14 A multiplicitáshoz kapcsoló másik fontos fogalom a katdinalitás, a számosság fogalma. 
A katdinalitás megadja az adott osztályban specifikálható előfordulások minimális, illetve 
maximális számát. 
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0..£: opcionális többes kapcsolat 

1..: 1 vagy többes kapcsolódás, kötelező többes kapcsolat 

22..44: egy objektumhoz [22.44] zátt intervallumnak megfelelő számú 
objektum kapcsolódhat 

9: ebben az esetben pontosan 9 objektum kapcsolódik a megjelölt osz- 
tály egy objektumához 

2 és 13 éttékeken kívül bármilyen számosság lehetséges: a számosság 
akár szövegesen is megadható. 

e A navigálhatóság iránya, az asszociáció bejárhatóságának iránya: a kap- 
csolatok mentén kommunikáció zajlik, amely lehet egy vagy kétirányú. 
A kommunikáció irányának jelölésére az osztályokat összekötő vonalra 
nyilat helyezünk. A navigáció azért fontos, mert megadja, hogy az asz- 
szociációval összekötött osztályok közül melyik kezdeményezi a 
kommunikációt, melyik osztály objektumainak kell ismernie a másik 
osztály objektumait. 


e. Megszorítás" (constraint): kotlátozás, ami az egyes modellelemek kö- 
zött definiált asszociációs viszony finomítására szolgál. A megszortí- 
tások a modellben kapcsos zárójelek íj között szerepelnek. Klasszi- 
kus példa a megszortításra, amikor azt akarjuk hangsúlyozni, hogy az 
asszociációban az egyik objektummal kapcsolatban levő objektumok 
tendezve legyenek elérhetőek, láthatóak. Az elemek tendezettségére 
előírt megszorítást az UML modellben forderedj; formában adjuk 
meg. 





15 Megszorítások megfogalmazására az UML specifikáció részét képező OCL (Object 
Consttraint Language) nyelv ad lehetőséget. Az OCL segítségével további szemantikai 
értelmezéssel lehet finomítani a modellt. 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza d 81 b 


Az UML Nyelv használata Osztályok, objektumok, osztálydiagram 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza d 82 b 





Osztálydiagram -— részlet 
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A kapcsolatok implementálása 


Az üzleti modellezés során az osztályok közötti kapcsolati viszonyok elég 
egyértelműek. Egyik osztály vagy objektum kapcsolatban van a másik osz- 
tállyal vagy objektummal. Az osztályok tulajdonságokkal jellemezhetők, 
meg tudjuk fogalmazni, hogy a két modellelem között milyen fokú kap- 
csolat van, de nem térünk ki, és nem is kell kitérni a kapcsolat megvalósí- 
tásának, az implementálásnak a kérdéseite. A kapcsolatokat csak fogalmi 
szinten éttelmezzük. 

finomítjuk. Véglegesítjük az attribútumok listáját, a specifikációt pontosít- 
juk az attribútumokra megadható jellemzőkkel (láthatóság, adattípus, kez- 
dőétték stb.) kiegészítve. Az eseménykövetési diagramok segítségével az 
objektumok üzeneteiből meghatározzuk az osztályok által nyújtandó szol- 
gáltatásokat, műveleteket. Az eseménykövetési diagramban az objektumok 
közötti üzenetváltások világosan mutatják az osztályok közötti asszociáció 
szükségességét. Ugyanis ha két objektum között kapcsolati viszony van, az 
azt is jelenti, hogy az osztályaik között asszociációnak kell lenni. A fejlesz- 
tésnek ebben a szakaszában az asszociáció már nem csak elvi/ fogalmi 
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szinten kerül megfogalmazásra, mint az üzleti modellezéskor, hanem az 
asszociációval két osztály közötti felelősségeket határozunk meg. 

Az objektumok közötti üzenetváltások azonban még mindig nem je- 
lentenek biztos információt a kapcsolat implementálására. A kapcsolatok 
kódolásáta az implementációs szakaszban kerül sot. 





A konceptuális modell 


A konceptuális modell csak a lényegi elemekre, az elemek közötti kapcso- 
latok leírására koncentrál. A diagramban ábrázolhatjuk a kapcsolat fokát, 
megadhatjuk az asszociáció nevét és különféle asszociációs viszonyokat 
ábrázolhatunk. 

















































































































ESETT EZ/ total 
Hauantity : Integer , -Hine items . 
53/ subtotal 1.2 Telnet áktbl 
IRdoseO 
02 o... 
forderedt 
V 1 
Customer 
Í EZname : String 
EZaddress : String 
Product A 
isumValue A 
name 
föprice 
EproductId KeyAccountCustomer Ordi SEESNET 
IRcreateO yi unt EödateOfLastPurchase 
contactName 



































A specifikációs modell 


A specifikációs szintű modell csak felelősségeket definiál, de nem kód 
szinten: egy Order-nek lesz olyan felelőssége, hogy megmondja melyik 
Customer-hez tartozik. A specifikációs modell készítésekor azt vizsgáljuk 
meg, hogy az egyik objektum a másik objektummal kapcsolatban a rend- 
szer által megvalósított szolgáltatás végrehajtása étdekében mit csinál, és 
mit ad vissza. Esetünkben tehát a specifikációs modell azt fejezi ki, hogy 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 83 b 


Az UML Nyelv használata Osztályok, objektumok, osztálydiagram 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza d 84 b 


egy Otder-nek az a felelőssége, hogy megmondja pontosan melyik egyedi 
azonosítójú Custornet tattozik hozzá. 


class Order 
( 
public Customer customer ( ) ; 
public Enumeration orderLines(); //Az Order osztálytól 
// lekérdezhetők hozzátartozó orderLine-ok. 





b 


Az implementációs modell 


Implementációs modell esetén már a felelősségek pontos megvalósítását is 
definiáljuk. Az implementációs osztálydiagramban azt írjuk le a példában, 
hogy minden Otder típusú objektum tattalmaz egy pointert, amelyik pon- 
tosan egy adott Customer objektumra mutat. 


AR Order osztály definíciója 


GNársis kondér UNA O edes osS zi ódéyele Eénáketkóg a 
( 
jovlodlates 

ONekese (0 ? 

ga séts gal sZazelere (8 


i1emej ILBELES? 

long INumber; 

CÜÚSE0MmEE: e mipthetús tom G0EThEeORdÉB 

Customert getTheCustomerOfTheOrder ( ) ; 
I; 


A gefl heCustomerOfr1 heOrder() függvény megvalósítása: 


Customer?  Order::getTheCustomerOÍíTheOrder () 
( 
ECETENNEBENEECÜSEOMS EG ETNEOTÁSE; 


12 





4.2.5. Az öröklődés 


Az öröklődés az OO-szemlélet egyik legfontosabb elve. Az öröklődés a 
modellelemek (use case-ek, osztályok) között értelmezett sajátos viszony. 
Lehetővé teszi, hogy a modellelem sajátjaként kezelje a nála általánosabb 
szinten definiált modellelem jellemzőit (a modellelemek jellemzőihez beál- 
lított láthatóság alapján). Az osztályok között éttelmezett öröklődési vi- 
szonyban az utód osztály (leszármazott) sajátjaként kezeli a nála általáno- 
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sabb/magasabb szinten levő osztály (ős osztály) attribútumait és művele- 
teit. Mint ahogy azt a 4.3. ábra is illusztrálja, az UML-ben az öröklődés jele 
egy ütes háromszögben végződő nyíl, a háromszög csúcsa az ős osztálynál 
található. 


ŐsOsztály 





























LeszármazottOsztályi LeszármazottoOsztálye 

















4.3. ábra. Öröklődési viszony 


Ötöklődési viszonyt kétféleképpen definiálhatunk a modellünkben: 


e Általánosítás (generalizáció — generalization: A különböző objektumok 
sokszor tattalmaznak közös jellemzőket (adatok, műveletek). Az álta- 
lánosítás az a folyamat, amikor ezeket a közös jellemzőket kiemeljük 
egy ős osztályba (alulról felfelé). Az általánosítás eredményeként létre- 
jön egy általános/közös sajátosságokat tartalmazó ős vagy szülő osz- 
tály, amelyhez tattozik egy vagy több speciális tulajdonságokkal ren- 
delkező al vagy gyerek osztály. Az ős osztály általában absztrakt osz- 
tály, olyan osztály, aminek nincsenek példányai. Az ős osztály szetepe 
ugyanis csak a közös sajátosságok egy helyen történő tárolása, segítsé- 
gével jelentősen egyszerűsödik a modellünk felépítése. A generalizáció 
használatának célja a kód újrafelhasználási fokának emelése a rend- 
szerben. 

e  Specializáció (bontosítás — specialization)h: A specializáció az a folyamat, 
amikor meglevő osztályokból származtatott osztályokat képezünk fi- 
nomítással (fentről lefelé). A finomítás célja az osztályok specifikáció- 
jának pontosítása, az objektumok egyedi jellegének megerősítése az 
egyedi jellegre utaló jellemzők definiálásával. A modellben a származ- 
tatott osztályok keresése során feltételezzük, hogy az osztályok általá- 
nosak (gyűjtőfogalmat jelenítenek meg). A specializáció során azt vizs- 
gáljuk, hogy újabb attribútumok és műveletek hozzáadásával milyen, a 
feladat szempontjából értelmes osztályok határozhatók meg. Az attti- 
bútumokat és az asszociációkat mindig a legáltalánosabb osztályhoz 
rendeljük. Ebben az esetben az ős osztály nem feltétlenül absztrakt. 
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Öröklődési viszony — Általánosítás 

A rendszetnek külön kell kezelni a nagyvásárlókat a többi ügyféltől. Van- 
nak olyan jellemzők (name és address attribútumok), amelyek mindkét 
ügyféltípusnál azonosak, azokat érdemes egy ős osztályba kiemelni. 














KeyAccountCustomer Ordi Cust 
EZpercentOfDiscount 771 E 
EZaddress BEEésl 
name szjggégjszsi 

dateOfLastPurchase 
EloontactName 


























Az általánosítás eredményeként léttehozhatjuk a Customer absztrakt osz- 
tályt, amelynek nem lehetnek példányai. A Customer osztály csak a közös 
jellemzőket tárolja, egyszerűsíti a modellt. A modellünk így kiemeli azt a 
tényt, hogy a különböző típusú ügyfeleink (KeyAccountCustomet, 
OtdinaryCustomer) azonos tulajdonságai a név (name) és cím (address) 
tulajdonságok. Az általánosítás azért teszi hatékonyabbá a tendszert, mert 
a kiemelt tulajdonságokat és műveleteket csak egyszer kell leírni. Esetünk- 
ben ez azt jelenti, hogy a name és az address tagváltozókat csak egyszer 
kellett definiálni, ill. ha később ezeket kezelő függvényeket definiálunk, 
akkor ezt is csak a Customer osztályban kell egyszer megtenni. 



























































Csstomer KERRRÉNESE 
Ename Absztrakt" 
Faddress 
KeyAccountCustomer 8 
B  FDiscount OrdinaryCustomer 
Iontadtáme FEZdateOfLastPurchase 
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Öröklődési viszony — Specializáció 

A fizetésekkel kapcsolatos infotmációkat — mint a kifizetés dátuma 
(paymentDate), vagy a végösszeg (total) — a Payment osztályban definiál- 
tuk. A nagyvásátlókra és a magánszemélyekre más fizetési feltételek vo- 
natkoznak. A nagyvásátlók átutalással teljesítenek, a többi ügyfél a helyszí- 
nen fizet, készpénzben vagy bankkártyával. Ha a Payment osztályhoz még 
hozzárendeljük a kiadási pénztárbizonylat (cashVoucher) attribútumot, 
akkor a CashPayment osztályt kapjuk. A pénzforgalmi jelzőszám (index- 
NumberOfMoneyCitculation) az átutalásos fizetésekhez (WiteTransfer 
osztály) kapcsolódó információ. 





Payment 
EzpaymentDate 
Htotal 

















A 














CashPayment Wirelransfer 
EZcashvoucher EöindexNumberOfMoneyCirculation 


























Az osztályok közötti öröklődési viszonyban öröklődési hierarchia, ún. öröklő- 
dési lánc is kialakulhat. Öröklődési lánc leírására a 4.4. ábra diagramja mutat 
példát. A hierarchiában azokat az osztályokat, amik nem örökölnek má- 
soktól sajátosságokat — vagyis nincsenek szüleik — gyökérnek (root) nevez- 
zük. Ezt a modellben a f/vofj megszorítással jelöljük, amit az osztály neve 
alá vagy megjegyzésbe írunk. Azokat az osztályokat, amik az öröklődési 
lánc legalsó szintjén helyezkednek el — vagyis nem örökítenek tovább jel- 
lemzőket — Zevé/ (leaf) osztályoknak nevezzük. Ezt a tényt a modellben is 
rögzíthetjük megszorításként, ilyenkor a f/eafy megszorítás az osztály neve 
alá vagy megjegyzésbe kerül. 
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LevéloOsztály leaf; 5 
megszorítás 

















4.4. ábra. Öröklődési lánc 


Az öröklési viszony lehet: 


e  egyszetes: egy osztálynak csak egy őse lehet. 

e többszörös: a kapcsolatban egy osztálynak több szülője is lehet. 

e többszintű: egy osztálynak legalább egy őse és több leszármazottja van. 
Ez az osztály az öröklődési lánc köztes szintjén helyezkedik el. 


4.3. Speciális fogalmak, asszociációs viszonyok 


Az osztályok leírását, az osztályok között értelmezett viszonyokat tovább 
finomíthatjuk. Az UML a fent említett, az osztályokat leíró alapvető ele- 
mek (attribútum, műveletspecifikáció, asszociáció, öröklődés) mellett még 
számos fogalmat, elemet és jelölést ajánl az osztálymodell pontosabb leírá- 
sára. 


4.3.1. Aggregáció és kompozíció 

Többször találkozunk olyan esettel, amikor egy objektum több másik ob- 
jektumból épül fel, vagyis egy objektum egy vagy több másik objektumot 
tartalmaz. Az UML lehetőséget ad összetett objektumok definiálására és 
kezelésére, aminek etedményeként az osztályok között ún. rész-egész vi- 
szony jön létre. A rész-egész viszonynak kétféle formája létezik (összetett 
objektum kétféleképpen keletkezhet: 


e  Aggregáció (aggregation): a tész-egész viszony gyengébb formája. A tároló 
objektum (az egész osztály) és az azt felépítő tészobjektumok (rész- 
elemek) elkülönülnek. Aggregációról csak akkor beszélünk, ha a rész- 
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oldal nem értelmes az egész nélkül. Abban az esetben, amikor az osz- 
tály a másik oldal nélkül is értelmes, akkor a két modellelem között 
egyszerű asszociációs viszony van. 

e  Kompozíció (composition): a tész-egész viszony erősebb változata. A tároló 
objektum a részobjektumokat is fizikailag tartalmazza. Ez azt jelenti, 
hogy együtt keletkeznek és szűnnek meg, vagyis az egész megszűntével 
a rész is megszűnik. Az egész oldal számossága csak 1 lehet. 


Az UML az aggregációt és a kompozíciót más szimbólummal jelöli. Az 
aggregációt egy rombusz, a kompozíciót egy sötétített tombusz szimboli- 
zálja, a rombuszok a tartalmazó osztály felöli oldalon helyezkednek el. 





Aggregáció 

Rendszerünkben az ügyfelek adatainak tárolásánál el kell tátolnunk az 
ügyfelek címét. Ha a címet a megye, a város, a kerület, az utca, a házszám, 
az emelet és az ajtó jellemzők megadásával akarjuk azonosítani, akkor a 
címet (address) érdemes külön egy cím (Address) osztályban definiálni. Az 
eljárás etedményeként a Customer és az Address osztályok között aggre- 
gációs viszonyt értelmezünk. 














EZaddress 
Iöfloor 
Iödoor 


























Kompozíció 
A tendszernek kezelni kell az egyes vásárlásokhoz/megrendelésekhez 
(Otder) tattozó termékeket. Az adott Otder-hez tartozó Product-okat az 
OtdetLine osztályban tároljuk. 

A tendelés (Otder) tendelési tételekből (OrdetLine) áll, a tendelési té- 
tel csak a rendeléssel együtt éttelmes. Az Order és az OtderLine között az 
aggregáció erősebb változatát, a kompozíciót értelmezzük. 
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4.3.2. Minősített asszociáció 





Minősített asszociációról akkor beszélünk, ha két osztály között asszociá- 
ciós viszony áll fenn és az egyik osztály egy tulajdonságot, attribútumot 
(minősítő — gualifier) használ fel kulcs gyanánt az asszociáció másik oldalán 
levő objektumok elérésére, azonosítására. Azt az osztályt, amelyik a másik 
osztály objektumait akarja a minősítő attribútum felhasználásával elérni, 
célosztálynak, a kapcsolatban részt vevő másik osztályelemet forrásosz- 
tálynak nevezzük. A rendszer működése során a meghatározott minősítő 
attribútumok (kulcséttékek) alapján kérdezhetők le az egyes elemek. Imp- 
lementációs szinten a minősített asszociáció rendszetint a célosztály objek- 
tumaiból képzett indexelhető tömb, vagy valamilyen más, kulcs szerinti 
keresésre alkaltmmas összetett adatstruktúra (pl. hashtábla) megjelenését 
eredményezi a fottrásosztályban. 





Minősített asszociáció 


A cég termékeit (Product) három különböző kategóriában kínálja ügyfelei 
tészére. Az egyes kategóriákba eső ugyanazon termékek minőségben és 
árban térnek el egymástól. Minden kategóriához egyedi termékkatalógus 
(ProductCatalog) készül. A modellben a ProductCatalog tartalmaz 
(contains) kapcsolatban áll a Product osztály objektumaival, amit az osztá- 
lyok közötti asszociáció megnevezése szemléltet. A ProductCatalog és a 
Product osztály elemei között a multiplicitás 1..t, azaz a ProductCatalog 
egy objektumához a Product-ból egy vagy több elem tartozik. 
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Product 
isumvValue ! 1. —— contains 1 
name 
iiprice 


EzproductId 





























Ebben a kapcsolatban a Product osztály productID attribútuma kulcsjel- 
lemzőként, ún. minősítőként szolgál a ProductCatalog számára. A 
productID a PtoductCatalog osztállyal tartalmaz kapcsolatban levő 
Product-ok közül pontosan meghatátoz egy objektumot. A minősített 
asszociáció eredményeként a két osztály között értelmezett multiplicitás is 
megváltozik, a minősítő attribútumot tattalmazó osztálynál a többes kap- 
csolat egyte változik, amit úgy értelmezünk, hogy a minősítő attribútum 
egyértelműen meghatározza, hogy mely objektum esetén jön létre az asz- 
szociációként jelölt kapcsolat. 











a 1 





























4.3.3. Asszociációs osztály 


Ha a modellben két osztály közötti kapcsolat jellemzésére, ill. annak létre- 
jöttéhez önálló tulajdonságok, esetleg metódusok tartoznak, akkor érde- 
mes ezeket egy külön osztályba specifikálni. Az így keletkezett osztályt 
asszociációs osztálynak (association class) nevezzük. Ilyen megoldásra akkor van 
szükség, ha két osztály elemei között több-több jellegű leképezést akarunk 
megvalósítani, de az egymáshoz tendelt párokhoz, ill. az asszociációval 
jelzett kapcsolat létrejöttéhez még további információkat is hozzá akatunk 
tendelni, amelyek igazából egyik osztályhoz sem tartoznak kizárólagos 
módon. 

Az UML-ben az asszociációs osztályt és a kapcsolatot szaggatott vonal 
köti össze. Az osztályoknak ezt a speciális változatát főként az elemzési 
fázisban alkalmazzuk. Látványosan étrzékeltethetjük vele az osztályok kö- 
zötti kapcsolat fontosságát, jellegét. A tervezési és az implementációs mo- 
dellben ezek az osztályok normál osztályokká szerveződnek. 
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Asszociációs osztály 


A cégnek két taktára (Store) van. Egy taktárban többféle tetméket tárol- 
nak (az asszociáció megnevezése: stores), egy adott tetmékből mindkét 
raktátban lehet készlet. Minden terméknek pontosan meg van határozva 
adott raktáron belüli tárolási helye. A rendelések összeállításakor a rend- 
szernek pontosan meg kell tudni adni: 


e a termék raktáron belüli tárolási helyét (stotagePlace), vagyis a termék 
melyik raktárban hol található. 

e Továbbá ismerni kell a raktári készletet (stored Ouantity), azaz adott 
termékből az adott raktárban hány darab található. 


A stotagePlace attribútumot a Product osztálynál nem célszerű tárolni, 
mett nem tudja megmondani, hogy a tetmék melyik raktárban van. Ha a 
storedOuantity attribútumot a Store osztályban definiáljuk, ez a raktárban 
levő összes tetmék databszámát adja vissza. Ha a Product osztályban tá- 
roljuk a storedOuantity-t, akkor az adott tetmék összkészletét kapjuk meg. 
A storagePlace és a storedOuantity attribútumok olyan információk, ame- 
lyek se nem a Store, se nem a Product osztályhoz nem rendelhetők kizátó- 
lagosan. Ezek az információk a kapcsolatra jellemző sajátosságok, amelye- 
ket egy külön osztályban, az ún. Storage asszociációs osztályban étdemes 
definiálni. 








Product !o..? stores 1... ! Store 


























Storage 
storagePlace 
storedOuantity 














4.3.4. Származtatott elemek 


Az UML-ben lehetőség van olyan elemek megadására, amelyek más, már a 
modellben definiált elemekből származnak, azokból számítódnak. A 
származtatásra leggyakrabban az attribútumoknál és az asszociációknál 
lehet szükség. A számított tulajdonságokat a tulajdonság neve előtt megje- 
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lenő per (/) jellel jelöljük. A számításhoz használt kifejezést kényszetként 
(megszorítás) kapcsos zárójelek íj között megadva írhatjuk le. 





Származtatott elemek 


Minden egyes megrendelés (Order) esetén a rendszernek meg kell tudni 
mondani az adott vásárláshoz tattozó végösszeget (total és a rendelési 
tételenkénti részösszegeket (subtota). A részösszeget a megvásárolt ter- 
mékek darabszáma (guantity attribútum az OrdetLine osztályban) és a 
termék ára (ptice attribútum a Product osztályban) szorzataként kapjuk 
meg. A végösszeg (total) önmaga is származtatott attribútum, a tendelés- 
hez tattozó részösszegek szummája. 





4.3.5. Sztereotípia 


Az UML-ben minden modellelemhez, így az osztályokhoz is rendelhetünk 
sztereotípiát. A sztereotípia alkalmazása tehát nem korlátozódik csak az 
osztályokra, használatuk általános az UML modellezésben. 

A sztereotípia a modellelemek tipizálása, minősítésre szolgál. Ha modell- 
elemekhez sztereotípiát akarunk rendelni, akkor a sztereotípia nevét karak- 
tersorának francia zárójelek közé tételével vagy szimbólummal, vagy a 
kettő egyidejű alkalmazásával adjuk meg. 
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A szteteotípia felhasználására vegyük példaként az elemzési munka- 
szakaszban az elemzési osztályok, ill. a belőlük példányosított objektumok 
minősítésére használt három típust. 


Elemzési osztályok sztereotípiái 


Az elemzési modellben az osztályok minősítésére a CCboundaryz5, a 
I Ccontrol55 és az CZentityz5 sztereotípiákat használhatjuk. A sztereo- 
típusok meghatározását az interakciós diagramok készítésekor, elemzése- 
kor lehet megtenni. 


e A Ccboundary-: sztereotípiával megjelölt osztályokat határ osztályok- 
nak is nevezik. A határ szó az osztálynak a tendszetben betöltött fel- 
adatára, szetepétre utal. Ezek az osztályok ugyanis a tervezett szoftvet- 
tendszet és a tendszer környezete közötti kommunikációt biztosítják, a 
tendszet és a környezete közötti kommunikációs kapcsolat megvalósí- 
tásáért felelősek. A határ osztályok valósítják meg a leendő rendsze- 
rünk interfészeit a külvilág felé. Interaktív alkalmazás fejlesztése esetén 
például a határ osztályok objektumai teprezentálják a felhasználói felü- 
let elemeit. Biztonsági, riasztó (étzékelő funkcióval rendelkező) rend- 
szerek fejlesztésekot CCboundaryz2 szteteotípussal látjuk el a rend- 
szer külső környezetéből étkező jelek feldolgozására alkalmas osztá- 
lyokat. 

e A Ccrontrolz2 sztereotípiával minősített vagy vezétlő névvel ellátott 
osztályok felelősek elsősorban a tervezett rendszer viselkedésének de- 
finiálásáért, kootdinálják és vezétlik annak működését. A vezétlő ob- 
jektumok jellemzően sok műveletet tartalmaznak, feladatuk más objek- 
tumok együttműködésének vezérlése. A CCconttolz3 sztereotípiát 
például ttanzakció-kezelést, erőforrás-kiosztást és hibakezelési felada- 
tokat végrehajtó objektumok minősítésére használjuk. 

e Az CZentitysz sztereotípiát entitás jellegű osztályok minősítésére 
használjuk. Az entitás osztályok jellemzően a rendszetben tátolt ada- 
tok tárolásáért felelősek. A tervezési modellben ezek az adatbázis ter- 
vezésekot fognak elsősorban fontos szerepet játszani. 


Az objektumok általában mindhárom fenti jellegből tattalmaznak vala- 
mennyit, tiszta , profilú"? objektum csak ritkán létezik. A megfelelő szte- 
teotípus kiválasztásánál a meghatározó jelleget kell figyelembe venni. 

Az elemzési osztályoknál a sztereotípusok használata megkönnyíti a 
diagramok összeállítását, értelmezését, elősegíti a szoftvertendszer rétegei- 
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nek (felület/prezentációs réteg, alkalmazáslogika, adattárolási logika) szét- 
választását. 


4.3.6. Absztrakt osztályok 


Az absztrakt osztályok (abstract class) speciális osztályok, amelyeknek nem 
hozhatunk létre példányait. Absztrakt osztályok specifikálásakor az osztály 
nevét döntött betűkkel kell írni. Az absztrakt osztályból mindig szátmazta- 
tunk további osztályokat, amelyek öröklik az absztrakt osztály attribútu- 
mait, műveleteit és asszociációit. 


4.3.7. Függőség 

A függőség (dependency) az UML-ben két elem egymásra hatását fejezi ki. Két 
(specifikációjának) változása a másik elem megváltozását okozhatja, ered- 
ményezi. A kapcsolatban az előbbi a független, az utóbbi a függő elem. A 
függési kapcsolatot irányított, szaggatott vonallal modellezzük. A nyíl irá- 
nya egyben meghatározza a függőség irányát. A nyíl a függő elemtől indul, 
és a felé az elem felé mutat, amitől az elem függ. 

Függőségi kapcsolatot gyakran adatcsere jellegű kapcsolatok leírására 
használjuk. Ilyen kapcsolat lehet például a felhasználói felület egy ablaka, 
mely adatokat kér be a felhasználótól (átmenetileg létező objektum) és az 
adatokat egy szakterületi, perzisztens módon eltároló objektum között. Az 
ablak esetében ahhoz, hogy teljesíteni tudja funkcióját, szüksége van a 
tároló objektumra. 

Függőségi viszonyt az UML bármely eleme között értelmezhetünk 
akár use case-ek, objektumok, komponensek, csomagok-elemek között. 
Általános tetvezési elv, hogy célszerű a fejlesztés sotán a modelleket úgy 
felépíteni, hogy bennük a függőségek száma lehetőleg minimális legyen. 


4.3.8. Osztályattribútum, osztályművelet 
Az osztályok attribútumait és műveleteit különleges szereppel és jelleggel 


tuházhatjuk fel, ún. scope specifikációt rendelhetünk hozzájuk: 


e A classífier típusú attribútumok (class-scope attibute) az osztály minden ob- 
jektumában, vagyis instanciájában ugyanazt az értéket veszik fel. 

e A classifier típusú műveletek (class-scobe operation) minden objektumra, va- 
gyis instanciára azonos módon lejátszódó műveletek. 


A classifier típusú attribútumokat és műveleteket az UML aláhúzással jelöli. 
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Osztályattribútum, osztályművelet 


A modellben osztályattribútum lesz a tetmékeket teprezentáló Product 
osztály sumValue attribútuma, ha ez az étték az összes termék értékét 
tárolja. A Product osztályban definiált objektumpéldányokat létrehozó 
create() művelet a Product minden objektumára azonos módon játszódik 
le, ezért ezt a műveletet a modellben osztályműveletként specifikáljuk. 





Product 
EsumvValue 
ISname 


(price 
fproductid 


IRcreateO 




















4.3.9. Template (paraméterezett, minta) osztály 


Komplex tendszerek fejlesztése esetén célszerű /ezyb/ate (mintaként hasz- 
nált) osztályokat létrehozni, amelyek az osztályokat valamilyen logika sze- 
rint csopottba fogva patamétetként általános definíciókat tartalmaznak. 

Ha a modellben ún. konténer (tároló) osztályokat definiálunk, akkor 
template osztályokkal adhatjuk meg bizonyos objektumok tárolásának és 
elérésének mintáját. Lista, ill. tömb osztályok esetén vannak olyan osztá- 
lyok, amelyek működése független az osztály tagváltozóinak (az objektu- 
mok állapotát leíró adatszerkezet) típusától. Például a lista osztály imple- 
mentációja független attól, hogy a lista int vagy double típust tárol. A tí- 
pustól függetlenül lehet az új elem beszúrását vagy egy meglévő elem tör- 
lését implementálni. 





Paraméterezett osztály 
Set paraméterezett osztály definíciója 


class Set cT5 // Set paraméterezett osztály definíciója 
í 

void insert íÍT newElement); 

void remove íÍT newElement); 
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FEmployee elemeket tartalmazó ,, Set" definiálása 








Set cEmployee- employeeSet; // Emloyee elemeket 
tartalmazó ost ee Etnasákl társat 





Paraméterezett osztály UML-ben 


AK 





.] 





Set 











IéremoveO 





4.4. A CRC-kártyák használata 


Az 1980-as évek végén az amerikai Tektronix elektronikai cég kutatólabo- 
tatóriuma volt az objektumorientált technológia egyik legelismertebb köz- 
pontja. A Smalltalk programozási nyelv alkalmazásában értek el kitűnő 
eredményeket, az OO-fejlesztések terén nagyon sok alapvető elvet ott 
munkáltak ki először a világon. Közéjük tartozott két munkatárs, Ward 
Cunningham és Kent Beck. 

Ők ketten dolgozták ki az ún. CRC-kártyák (CRC cards) használatának 
elvét. Az elnevezés eredete a következő: CRC: Class — Responsibility — 
Collaboration (Osztály — Felelősség — Együttműködés). 

Cunningham és Beck nem diagramok alapján alakították ki fejlesztési 
modelljüket, hanem táblázatos beosztású lapokon (kártyákon) írták le az 
egyes osztályokat. Ebben a leírásban nem metódusokat és attribútumokat 
adtak meg, hanem az osztályokhoz rendelhető felelősségekez. 

A felelősség itt valójában annak a magas szintű leírása, hogy mi a fő 
célja az illető osztálynak. Ebben a megközelítésben nem koncentrálunk 
arra, hogy milyen adataink vannak, hogy milyen folyamataink vannak. 
Ehelyett arra összpontosítunk, hogy minél pontosabban, minél egyértel- 
műbben meghatározzuk egy osztály működésének a célját, mégpedig egy 
tövid, tömör leírás formájában. A leírásnak el kell fétnie egy adott lapon, 
kártyán. Egy ilyen CRC-káttya tartalmát mutatjuk be a 4.5. ábrán. 
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cOsztály neve: 
Order 
§i pink kélgütl való meglétének Order Line 
cFelelősség:  JAz ár meghatározása Order Line sEgyüttműködés: 
A kifizetés érvényességének ellenőrzése Customer 





Áruk elküldése a megrendelő címére 














4.5. ábra. CRC-káttya alkalmazása 


A káttyák elkészítésére speciális szoftvert eszközök is rendelkezésre állnak. 
Ezt demonstrálja a 4.6. ábra, ugyanatra a példára. 




















CRC Tool - [SWE.CRC - Order] [-fojx] 
EHFiz Edt View Gezte Options Window  Hzlp -]laixi 
ETEEJEI(RTETE[E] [Esorcia 16 - (pej 

F 
Class: Order [docAuthhh e] 
A tételek raktáron való meglétének ellenőrzése Order Line 
Az ár meghatározása Order Line 
A kifizetés érvényességének ellenőrzése Customer 





Aruk elküldése a megrendelő címére 





























z] 


For Help, press Fi 18pt. [Ex7 


4.6. ábra. CRC-káttya készítése CRC-eszközzel " 





16 A CRC-eszköz az Ixtlan Software terméke. 
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A CRC-ben a második C az együtíműködésre utal. Az együttműködő fél egy 
másik osztály, amely egy adott felelősséghez kötődik. Egy felelősséghez 
tehát azt kell megadni, hogy melyik osztály az, amelyre, vagy melyik osztá- 
lyok azok, amelyekre szükség van ahhoz, hogy az adott felelősséget teljesí- 
teni lehessen. Ezekkel az osztályokkal kell tehát dolgozni az adott felelős- 
ség esetében. Mint látható, ez a megoldás tulajdonképpen magas szinten 
tünteti fel az osztályok közötti kapcsolatokat. 

A CRC-káttyák igazi értéke abban áll, hogy a fejlesztők közötti hasz- 
nos és élénk megbeszélést segítik elő. Akkor a leginkább előrevivők, ami- 
kor egy use case-en megyünk keresztül, és azt nézzük meg, hogy a use 
case-t hogyan fogják az egyes osztályok megvalósítani, leképezni. A fej- 
lesztők azt nézik a kártyákon, hogy az osztályok hogyan működnek együtt 
a use case-en belül. Ebben a folyamatban azt alakítják ki, hogy mik lesznek 
az elvátható felelősségek, amiket végül is tá fognak ítni a kártyákra. 

A felelősségekről való vita és döntés azért fontos, mert elviszi a fejlesz- 
tőket attól, hogy az osztályok belső világával foglalkozzanak, azok részle- 
tes működésével, adataival, és e helyett inkább az osztályok magasabb 
szintű működésére tudjanak koncentrálni. Ez a tervezési szemlélet azt 
segíti elő, hogy a jól kiérlelt, helyes döntések magasabb szinten szülesse- 
nek, és a döntések részletes megvalósításával csak később kelljen foglal- 
kozni. Nincs rosszabb annál ugyanis, mint ha egy felső szinten hozott 
tossz döntést kell az alsóbb szinteken végigvinni, kivitelezni. 

Fowler gyakori hibának észleli a fejlesztők körében azt, hogy hosszú 
listákat állítanak össze az alsó szintű felelősségekből. Szetinte ez a lényeg- 
látás hiányát tükrözi. A felelősségeknek rá kell férniük egyetlen kártyára. 
Ugyanakkor egy kártyán nem érdemes három-négynél több felelősséget 
feltüntetni. Ha ennél többre volna szükség, akkor érdemes megfontolni 
azt, hogy egy osztályt több részre, több osztályra bontsunk, ami a felelős- 
ségek tisztább szétosztását segítené elő. 


Mikor használjunk CRC-kártyákat? 


A CRC-káttyákat elsősotban az objektumorientált analízis munkafolyama- 
taiban használják. Ilyenkor a fejlesztő team mindegyik osztályra elkészíti a 
megfelelő kártyát. 

Ezt a megközelítést a későbbiek folyamán kibővítették. Először is, egy 
CRC-kártya gyaktan tartalmazza az osztály metódusait és attribútumait, 
azáltal, hogy pontosítva adja meg egy , felelősség" leítását. Másodszor 
pedig, a kártyák használata helyett ma már számítógépes segédeszközöket 
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vesznek igénybe, ahol webes környezetben kommunikálnak egymással a 
team tagjai, és ezáltal jön létte egy-egy osztály végső CRC-reprezentációja. 
Ezt a folyamatot CASE-eszközök is segítik, mint például a Syszez Architect, 
amely külön komponenseket tartalmaz a , kártyák" számítógépes előállítá- 
sához. 

A CRC-kártyák hasznossága abban áll, hogy a team-tagok közötti in- 
terakció sotán kiderülhet, hogy egy osztályban hibás vagy hiányzó mezők 
vannak, akár metódusok, akár attribútumok tekintetében. Az osztályok 
közötti viszony is világosabbá válik a káttyahasználat során. Igen jónak 
bizonyult az a megoldás, amikor a kártyákat szétosztják a fejlesztőcsoport 
tagjai között, akik ezután kimunkálják a saját osztályuk felelősségeit. Így 
például valaki azt mondhatja, hogy , én vagyok a Date (Dátum) osztály, és az 
én felelősségem az, hogy új dátum-objektumokat hozzak létre". Egy másik 
team-tag etre felvetheti, hogy neki további funkciókra van szüksége a Date 
osztályból. Ilyen újabb funkció lehet például az, hogy a dátumok szokásos 
formátuma konvertálódjék át egészszámmá úgy, hogy a konvetzió az 
1900. január 1-jétől kezdve eltelt napok számát adja meg egy dátumra. 
Ezáltal két dátum között eltelt napok száma egyszerű kivonással határoz- 
ható meg, vagyis csak a két megfelelő integer különbségét kell képezni. 
(Az ilyen számítások elsősorban a pénzügyi, banki rendszerekben szüksé- 
gesek, például a különböző időtartamokra eső kamatok vagy az inflációs 
értékek megállapításánál.) 

Mindezek után megállapíthatjuk, hogy a CRC-kártyák felelősségeinek 
egyenkénti kimunkálása nagymértékben elősegíti annak igazolását, hogy a 
végül léttehozott osztálydiagtam teljes és korrekt lesz. 

Fowler szerint mindenképpen érdemes a használatukat kipróbálni a te- 
am-munkában, és meggyőződni arról, hogyan válik be, hogyan fogadja be 
a team. Különösen akkor érdemes használatba venni, ha a team túlságosan 
belebonyolódik a tészletekbe, még túl korán a fejlesztési folyamatban. 
Vagy pedig akkor, amikor nem sikerült világosan definiálni az egyes osztá- 
lyok funkcióját. 

A CRC modellezés eredményeit fel tudjuk használni az osztálydiagra- 
mok elkészítésénél. Mindez annak tudható be, hogy ezek az UML-diagta- 
mok az osztályok működésével és a köztük levő kapcsolatokkal vannak 
összefüggésben, csakúgy, mint a CRC-kártyák. Ilyenkor feltétlenül szükség 
van arra, hogy az osztálydiagramok mindegyik osztályához meg legyen 
adva azok felelősségi kör a CRC-kártyán. 
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5. Interakciós diagramok 


5.1. Az objektumok közötti együttműködés 


Egy objektamorientált rendszerben a számítási műveleteket az egymással 
információs kapcsolatban álló objektumok végzik el. Ezeknek a kapcsola- 
toknak a tervezés során történő modellezése alapvető fontosságú. Az 
UML-ben ezt a célt az ún. zzterakciós diagramok (interaction diagram) szolgálják. 

Az interakciós diagram alkalmazásának tipikus esete az, amikor egy ki- 
tagadott use case viselkedését, működését írjuk le vele. Ez a diagram ilyen- 
kor a use case-ben megnyilvánuló objektumokat mutatja be, a közöttük 
folyó vezérlési információcsetrével, vagyis az elküldött üzenetekkel együtt. 

Hogy betekintést nyerjünk ebbe a folyamatba, az alábbiakban példa- 
ként bemutatjuk, hogy a Java programozási szférában miként kommunikál 
egymással két objektum. 

Egy Java-osztály olyan programegység, ami konkrét objektumokban 
ölt testet, azokban realizálódik a számítógépes végrehajtás során. Egy ob- 
jektumban metódusok vannak, amelyek önállóan kezelhető, futtatható 
kódszegmensek, kódrészek. 

Egy objektumhoz tartozó metódus a következő formátumú iizemeítel 
(zessage) indítható el az objektumon kívülről, mégpedig egy másik objek- 
tumból: 


Objektum neve . üzenet (atgumentuml, artgumentum2, ... , argumentumn); 


Itt szokás még a fogadó (bívott) objektum elnevezés is, ill. üzenet helyett a 
szelektor elnevezés. A szelektot a fogadó objektumon belül annak a metó- 
dusnak a kiválasztására szolgál, amelynek az üzenet szól. Tehát a fogadó 
objektumon belül a kiválasztott (hívott) metódust az üzenet maga választja 
ki. Az argumentumok pedig nem mások, mint az üzenethez tattozó vezét- 
lő pataméterek. Ha a metódus atgumentum nélkül működik, akkor ez a 
lista ütes matad. 

Egy üzenet mindig egy kiválasztott metódust indít el az objektumon 
belül. A metódus lefutása után a vezérlés az üzenetküldő utasítás utánra 
adódik vissza, a klasszikus hívás-visszatérés mechanizmusnak megfelelően. 
Megemlítendő még, hogy egy objektumon belüli metódusok is hívhatják 
egymást. A hívási folyamatot az 5.1. ábrán illusztráljuk. 
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5.1. ábra. Egy metódus lefuttatása üzenetküldéssel 


Példák a hívásra: 
localComputets . addComputert (, Vax1"); 
localComputets . rtemoveComputer (, Vax2"); 


A két utasítás egy olyan programból van kiemelve, amelyben az első hívás 
hatására a localComputers objektum addComputer nevű metódusa az objek- 
tum által tárolt listába felveszi a [/ax7 tartalmú szövegkonstansot. A másik 
hívás hatására ugyanebből a listából törlődik a [/ax2 elem. 

Az UML-ben kétféle interakciós diagram létezik: 


e  Szekvenciadiagram, vagy más néven eseménykövetési diagram. Az angol el- 
nevezés: segyence diagram. 
e. Együttműködési diagram (collaboration diagram). 


Az interakciós diagramok valójában az egyes use case-ek végrehajtási pél- 


.4.. 


A szekvenciadiagramok az objektumok időbeli viselkedésének mene- 
tét, folyamatát tükrözik, az objektumok közötti üzenetek időbeli követésé- 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 102 b 


Az UML Nyelv használata Interakciós diagramok 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 103 b 


vel együtt. Arra használhatók, hogy egy adott use case szcenárió kölcsön- 
hatásait szemléltessék. 

Az együttműködési diagramok ezzel szemben az osztálydiagrammal 
való kapcsolatot jelenítik meg. Az objektumok közötti kölcsönhatást üze- 
netek halmazaként ábrázolják, ahol az üzeneteket az egyik objektum küldi 
a másiknak, valamilyen részfunkció teljesítése céljából. Ennek a megjeleni- 
tési módnak fontos sajátsága az, hogy az üzenetek csoportosan, bekövet- 
kezésük sorrendjében vannak feltüntetve. 

A szekvenciadiagramok és az együttműködési diagramok valójában 
egymással ekvivalens leírást adnak. Mindkettő azt mutatja, hogy az objek- 
tumok közötti kölcsönhatás miként megy végbe üzenetek váltása révén. 
Egy bizonyos dinamikus nézetet adnak a rendszertől azáltal, hogy grafiku- 
san jelenítik meg az objektumok fuzász időben (at run time) végbemenő mű- 
ködését. A különböző működési folyamatok különböző forgatókönyveket 
valósítanak meg. 

A következőkben külön-külön tátgyaljuk és mutatjuk be a két diagram- 
típust. 


5.2. Szekvenciadiagramok 


A szekvenciadiagram használatát egy példán keresztül fogjuk ismettetni. 
Ehhez egy use case-ből indulunk ki, amely a következő működést valósítja 
meg: 


e Az Order Entry (megrendelési belépés) képetnyő-ablak egy , prebare" 
(előkészítés) üzenetet küld az Order-nek (megrendelés). 

e Az Order egy , prepare" (előkészítés) üzenetet küld mindegyik Order Line 
(megrendelési tétel) számára, éspedig azokra a tételekre vonatkozóan, 
amelyek az Order-ben (megrendelésben) szerepeltek. 

e Minden egyes Order Line ellenőtzi a neki megfelelő, hozzá tartozó S7ock 
Item-et (taktári tételt), azzal a céllal, hogy kiderüljön, megvan-e a kellő 
mennyiség a raktáron a megrendelt tételből. 

— Ha az ellenőtzés , igaz" eredményt ad vissza, az Order Line az aktu- 
ális Szock [fem-et annyi darabbal csökkenti, amennyi az Order-ben 
szerepelt. 

—- Ha nincs meg maradéktalanul a megrendelt mennyiség az adott té- 
telből, akkor a Szock I/em egy új utánpótlási szállítást, feltöltést igé- 
nyel meg. 
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A fent leírt folyamat szekvenciadiagramját az 5.2. ábrán láthatjuk. A diagra- 
mon egy objektum egy dobozként van ábrázolva, egy függőleges szaggatott 
vonal tetején. Ezt a függőleges vonalat életvonalnak (life line) nevezzük. Az 
életvonal az objektum működésének lefolyását reprezentálja, az események 
menetét követve. (Ezért van használatban az eseménykövetési diagram elneve- 
zés is.) Az itt látható ábrázolási mód egyébként Jacobsontól származik. 

A két objektum közötti üzenetet egy vízszintes nyíl ábrázolja, a két 
életvonal között húzódva. Az üzenetek abban a sorrendben, szekvenciá- 
ban követik egymást, fentről lefelé haladva, ahogyan egymás után bekö- 
vetkeznek. A nyilakon fel van tüntetve az üzenet neve. Ehhez még hozzá 
lehet írni az üzenet atgumentumait (vezétlési patamétereit), továbbá bizo- 
nyos vezétlési információt is. 
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5.2. ábra. Egy szekvenciadiagram 


Egy objektum önmagának is küldhet üzenetet. Az ilyen eseményt egy visz- 
szakanyarodó nyíl jelzi, a saját életvonalból kiindulva, és ugyanoda vissza- 
térve. Ezt öndelegálásnak (self-delegation-nek) is szokás nevezni. 

A vezérlési információ megadására még két másik lehetőség is kínál- 
kozik: 


e Meg lehet adni annak a jfeZtételét (Condition), hogy mikor, mitől függően 
lesz elküldve egy üzenet. Itt például: needsToReorder —— true esetén 
az Reorder Item) (tétel utántendelése) objektum léttehozására (new) és 
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elindítására ketül sor. Ekkor az objektum alatt tetmészetesen az élet- 
vonala is megjelenik. 

e A másik hasznos vezérlési jelölés az ún. iszyétlési jel (iteration marker), ami 
azt mutatja, hogy egy üzenet több alkalommal lesz elküldve. A példá- 
ban annyiszor, ahány fajta megrendelési tétel szerepelt a listában. Ezt a 
többszötözést a § brepare () formában leírt üzenet fejezi ki, ami azt is 
jelenti egyben, hogy ennyi darab Order Line (megrendelési tétel) objek- 
tum lesz megszólítva, aktivizálva, mivelhogy mindegyik lehetséges té- 
telhez egy külön objektum tartozik. 


Az ábrán jól áttekinthető és követhető az objektumok közötti események 
menete, ami igen előnyös tulajdonsága a szekvenciadiagramoknak. Az 
00-ptogtamozásban ez különösen fontos. Ott ugyanis sok olyan metó- 
dus (művelet) szerepelhet az egyes osztályokban, amelyek egymás utáni 
működtetése a szekvenciadiagram nélkül nehezen volna követhető, átte- 
kinthető, kézben tartható. A forráskód ebből a szempontból kevésbé 
használható, bár megvannak benne az objektumok, amelyek egymás me- 
tódusait hívják az üzeneteken keresztül, de ebből a sorrendiség nehezen 
vehető ki. Egy olyan programozónak, akinek még új az OO-technika, kü- 
lönösen sok gondot okozna a kódban való eligazodás. 

Az 5.2. ábra tattalmaz egy visszatérési (Rejwm) nyilat is. Ez nem jelent 
semmilyen új, igazi üzenetet, hanem csak egy üzenetet követő visszatétést. 
Használata nem kötelező, mivel a diagram e nélkül is egyértelmű. Olyan, 
mint a hívásból való visszatérés. Az 5.3. ábrán A hívja B-t, ami után A 
visszakapja a vezérlést. A hívási kapcsolat kifejezésére itt elegendő lenne a 
felső nyíl. 


























5.3. ábra. Hívási és visszatérési kapcsolat két modul között 


A Reiurn nyilat akkor étdemes használni, amikor az javítja az áttekinthető- 
séget a diagramon. A példában csak az illusztráció miatt használtuk, el is 
lehetett volna hagyni, mert nem segített az áttekinthetőségen. 
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5.3. Konkurrens folyamatok és az aktiválások 


A szekvenciadiagramok alkalmasak arta is, hogy konkurrens (egyidejű) 
folyamatokat lehessen velük leírni. Az 5.4. ábra olyan objektumokat tat- 
talmaz, amelyek egy banki tranzakciót ellenőriznek. 
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5.4. ábra. Konkuttens folyamatok és aktiválások 


Amikor a Iransaction (tranzakció) nevű objektum kerül létrehozásra (sem 
parancs), akkor az a következő lépésben létrehoz egy Iransaction Coordina- 
for (ttanzakció-kootdinátor) nevű objektumot (ismét em). A Coordinator- 
nak az a feladata, hogy ellenőrizze a tranzakciót. Ezt úgy végzi el, hogy 
annyi különböző ellenőrző objektumot hoz létre, ahány egymástól eltérő 
ellenőrzési feladatot kell a banknál az ottani szabályok szerint ellátni. Eb- 
ben a példában kettő ilyen Iransacíion Cbecker (ttanzakció-ellenőrző) objek- 
tum szerepel, (first és second). Mindkettőnek megvan a maga külön megsza- 
bott ellenőrzési funkciója. 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 106)b 


Az UML Nyelv használata Interakciós diagramok 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 107 b 


A két ellenőrzési tevékenység egymástól függetlenül folyik, semmilyen 
szinkronizálásra, ütemezésre nincsen velük kapcsolatban szükség. Ezt úgy 
is megfogalmazhatjuk, hogy a két objektum egymással aszinkron módban 
működik. Az aszinkronitás egyszerűbbé teszi a vezétlésüket, mivelhogy 
bármelyikük indítható először is, meg másodszor is. Ha kettőnél több fajta 
ellenőrzésre lenne szükség, azok is ugyanígy, egymással párhuzamosan, 
egymással egyidejűleg tudnának működni. Ezek a folyamatok a futás szer- 
vezése, az eredmények feldolgozása szempontjából egyzdejűlegesek, tnás szó- 
val £onkurrensek. Természetesen a gépi végrehajtás szempontjából nem 
tudnak párhuzamosan futni, hanem vagy egymás után, vagy valamilyen 
felváltásos szervezésben. (A valódi párhuzamos futás többprocesszoros 
számítógépet igényelne, de itt csak egy processzott tételeztünk fel.) 

Amikor egy Iransaction Cbecker befejezi a tevékenységét, akkor erről ér- 
tesíti a Iransaction Coordinator-t. A Coordinator ekkor megnézi, hogy bejött-e 
a másik visszajelentkezés is, vagyis hogy mindkét Checker elvégezte-e a 
feladatát. Ha ez még nem töttént meg, akkor a Coordinator nem csinál sem- 
mit, csak várakozik. Ha viszont mind a két visszajelzést megkapta, és mind 
a két ellenőrzés rendben találta a tranzakciót, akkor a Coordinator éttesíti a 
Transaction objektumot, hogy minden teljes tendben van. 

Az 5.4. ábrán a szekvenciadiagramok több új tajzeleme figyelhető meg: 

Az egyik ilyen az ún. a£ziválás, ami az életvonalon egy lefelé nyúló tég- 
lalap. Ez addig tart, amíg az adott objektum egyik metódusa (művelete) 
aktív, vagyis működésben van: vagy végtehajtódik a benne levő utasítá- 
sokkal, vagy pedig várakozik arra, hogy megkapja a várt információt egy 
Return után. 

Fowler tapasztalatai szerint sokan vannak, akik az aktiválást minden 
helyen alkalmazzák, feltüntetik. Ő maga úgy véli, hogy ezzel nem sok 
plusz információt visznek be a végrehajtás menetébe. Ebből kifolyólag 
csak a konkurrens folyamatok megjelenítésénél él a használatukkal. 

A másik új jelölés a fél nyílfej, amely egy aszinkron típusú üzenetet fejez 
ki. Mint láttuk, az aszinkronitás itt azt jelentette, hogy az ilyen jellegű üze- 
net (hívás) bármikor kiadható, vagyis a hívó objektumot semmi nem kor- 
látozza az üzenet kiadásának időpontját illetően. Ez egyben azt is jelenti, 
hogy az aszinkron üzenet semmilyen módon nem kortlátozza a hívót, az a 
hívás után szabadon folytathatja tovább saját feldolgozó tevékenységét. 
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Egy aszinkron üzenet három különböző dolgot tud etedményezni: 


e Egy új programozási szálat hoz létre, ami ebben az esetben egy aktivá- 
lásnak a kezdetéhez fog kapcsolódni. (Mármint a szálat képviselő akti- 
válás kezdetéhez.) 

e Létrehoz egy új objektumot. 

e Kommunikál egy olyan szállal, amely éppen futásban van. 


A harmadik új jelölés az objektum zör/ése, amit egy nagyméretű X jel repre- 
zentál. Az OO-technikában ezt az utasítást egy objektum deszrukciójának, 
elpusztításának, vagy megszüntetésének nevezik. Hatására az objektum futása 
megszakad, miközben maga az objektum is eltűnik a memóriából. 

Egy objektum kétféle módon szűnhet meg: 


e Vagy saját magát szünteti meg öndestrukcióval (self-destruction), amint az 
5.4. ábrán is látható. 

e Vagy pedig egy másik objektum pusztítja el egy megfelelő üzenettel, 
amint az 5.5. ábrán látható. Ez az üzenet a ,,£z///. 
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5.5. ábra. Szekvenciadiagram tranzakció-ellenőrzéssel 
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Az 5.4. ábra a sikeres tranzakciót ítta le, míg az 5.5. ábra a sikettelent. Az 
utóbbi esetben az első Cbecker hiányosságot észlelt, és ezt követően már ki 
lehetett lőni, el lehetett pusztítani a második Cbecker-t. 

A két ábrán jól látható az önbívás (ön-delegálás) menete, ami itt az aktivá- 
láshoz kapcsolódik. Ezt az egymásra helyezett aktiválási mezők még job- 
ban kiemelik, ahhoz képest, mintha csak a puszta életvonalak lennének 
feltüntetve. Ily módon szemléltetni lehet azt is, hogy mikor kerül sor egy 
hívásra az önhívást követően, akár a hívó, akár pedig a hívott metódusban. 
Ezt az egymásra helyezett mezők teszik lehetővé. 

Az 5.4. ábta és az 5.5. ábra két szremáriót mutat be a tranzakció- 
ellenőrzés lefolytatására. Nyilvánvaló, hogy ez két különböző use case-t 
jelent. A két szcenáriót külön rajzoltuk meg. Lehetett volna egyben is 
megtajzolni őket, de azzal túl komplikálttá, túl áttekinthetetlenné vált vol- 
na a kép. 


5.4. Együttműködési diagramok 

Az interakciós diagramok második fajtája az ún. együttműködési diagram 
(collaboration diagram). Az objektumok ezeken is téglalapokkal vannak fel- 
tüntetve, és a köztük levő üzeneteket ugyancsak nyilakkal jelöljük, hason- 
lóan a szekvenciadiagramokhoz. A különbség itt abban nyilvánul meg, 
hogy az üzenetek sorszámokkal vannak ellátva, ami az egymás utáni sor- 
tendiség megadására szolgál. A másik eltérés az, hogy az objektumok tet- 
szőlegesen helyezhetők el a tajzon, a szetint, ahogyan a számozott üzene- 
tek ezt megkívánják. 

Mint látni fogjuk, ez az ábrázolási mód nehezebbé teszi a sottendiség 
áttekintését, követését ahhoz képest, hogy egymás alá rajzolnánk az üzene- 
teket, mint a szekvenciadiagramokon. Másfelől azonban a tétbeli eltende- 
zés lehetővé teszi, hogy más dolgokat könnyebben lehessen megmutatni. 
A tajzon való elrendezésből jobban kitűnik, hogy miként vannak össze- 
kapcsolódva az objektumok, hogyan vannak statikusan összekötve egy- 
mással. 

Mindehhez kétféle számozási séma rendelhető. Az egyik az egyszerű, 1- 
től egyesével növekvő számozás (5.6. ábra), a másik pedig egy lebontásos, 
decimális osztású (tizedes osztású) számozás (5.7. ábra). A két ábra ugyanazt a 
diagramot jeleníti meg, különböző számozással. 

Régebben az egyszerű számozási szisztémát használták a legtöbben. 
Az UML-en belül ma már a tizedes osztású számozás van elterjedve. Ez 
azétt lett így, mert világosan kifejezi, hogy melyik művelet (metódus) me- 
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lyik műveletet (metódust) hívja közvetlenül. (Ugyanakkor azonban ez 
megnehezíti a közvetlen sorrendiség követését.) 

A választott számozási rendszertől függetlenül itt is megadható az a 
kiegészítő vezétlési információ, amit a szekvenciadiagramoknál is lehetett 
használni. 

Az 5.6. ábrán és az 5.7. ábrán látható az is, hogy az UML miként neve- 
zi el az objektumokat. Ennek az UML-szabványos alakja a következő: 


objectName : ClassName 


ahol vagy az objecíNazme (objektum neve), vagy a ClassNaze (osztály neve) 
elhagyható. De a kettő közül csak az egyik! Ha az objektum nevét hagytuk 
el, akkor is ki kell tenni a kettőspontot, hogy lássuk azt, hogy az osztály 
neve van feltüntetve, nem pedig az objektum neve. Eszerint a 


, Macallen Line : Order Line? 


az Order Line osztály egy példányát jelenti, amit Maca/len Line-nak nevez- 
nek. (A Macallen egy amerikai édességmátka.) 
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5.6. ábra. Együttműködési diagram egyszetű számozással 
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5.7. ábra. Együttműködési diagram decimális osztású számozással 


5.5. Felhasználási példa könyvtári kölcsönzésre 


A use case diagramok átfogó képet adnak a szoftvet tendszetben szereplő 
aktorokról, valamint azoktól az akciókról, amelyeket a tendszer hajt végte. 
Az akciók észlelhető etedményt adnak, amelyek az aktorok számára lesz- 
nek értékesek. A diagramok egy tendszett a teljes összefüggésében ítnak 
le, azáltal, hogy a funkcionalitást olyan tranzakciókra bontják, amelyek 
ugyancsak hasznosak az aktorok számára. Emellett azt is mutatják, hogy 
milyen kölcsönhatás lép fel az aktotok és a tranzakciók között. 

A tetvezett tendszer működésének leírásakor jól használható, a fejlesz- 
tők által is támogatott use case technikát nemcsak a szoftvetkövetelmé- 
nyek leírására használhatjuk. A use case-eket etedményesen alkalmazhat- 
juk a tendszetfejlesztés első fázisában az üzleti folyamatok, az üzleti köve- 
telmények leírásakor. A tendszerfejlesztésnek ebben a szakaszában még 
nem tétünk ki a szoftverrendszer működésére, csak azt vizsgáljuk, hogy a 
fejlesztendő szoftvertendszernek milyen üzleti folyamatok (üzletmenet) 
számítógépes támogatását kell megvalósítani. 

A modellben az üzleti folyamatok leírásakor használt use case-eket bu- 
siness use case-eknek nevezik. A modellben a business sztereotípia fejezi 
ki, hogy a use case-eket üzleti folyamatok, üzleti követelmények leírására 
használjuk, amik támogatásáta egy szoftvettendszett akatunk fejleszteni. A 
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CASE fejlesztőeszközök többsége ma már szinte kivétel nélkül támogatja 
az üzleti folyamatok use case-ek és aktorok segítségével történő leírását a 
business sztereotípia megadásával. Vannak fejlesztőeszközök, amik a bu- 
siness jelleg szemléltetésére másfajta szimbólumot használnak. A business 
sztereotípiájú modellelemek grafikus megjelenítésekor a modellelemek 
jobb oldalán elhelyezett ferde vonallal utalnak az üzleti jellegre. 

Tekintsük példaként a könyvtári kölcsönzést, amelynek business (üzle- 
ti) use case diagramját az 5.8. ábra tünteti fel. 











Könyvtári köcsönzés 





Ügyfél ES Könyvtáros 


Könyvtári update-olás 








5.8. ábra. Könyvtári kölcsönzés business (üzleti) use case diagramja 


A tetvezett rendszer lehetővé teszi, hogy kölcsönözni és visszajuttatni 
tudjuk a könyveket. Ezek az akciók az ügyfeleket és a könyvtárosokat von- 
ják egy körbe. A könyvtárosok ezen kívül még update-olhatják (naprakész 
állapotba hozhatják) a könyvtári állományt, azáltal, hogy új könyveket 
vesznek fel a katalógusba, ill. törlik a leselejtezett régieket. 

A kölcsönzés és visszajuttatás folyamatainak egy lehetséges forgató- 
könyve az 5.9. ábra szekvenciadiagtamjával valósítható meg. Az ábrán sze- 
replő objektumok nevei: Customer (Ügyfél), Librarian (Könyvtáros), valamint 
Catalogue (Katalógus). Kölcsönzéskor az ügyfél a tagsági káttyáját bemutatja a 
könyvtárosnak, aki ellenőrzi, hogy az nem jJátt-e le. Ha a kártya étvényes, 
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akkor a katalógus ellenőrzésére kerül sor, hogy rendelkezésre áll-e a kere- 
sett könyv. Ha igen, akkor az ügyfél kikölcsönözheti azt. Hasonló módon 
megy végbe a könyv visszajuttatása is. 
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5.9. ábra. A Könyvkölcsönzés business use case-ben definiált 
működést leíró szekvenciadiagram 


Az 5.10. ábra ugyanezt a szcenáriót írja le együttműködési diagram segít- 
ségével. Az események időbeli sorrendjét az objektumok közötti kapcsola- 
tokon feltüntetett sorszámozás fejezi ki. 
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5.10. ábra. A Könyvkölcsönzése business use case-ben definiált működés 
megvalósításában részt vevő objektumok kommunikációját leíró 
együttműködési diagram 


5.6. A kétféle diagram összehasonlítása 


A különböző fejlesztők nem egyfotmán preferálják a két diagramot. Van, 
aki az egyiket részesíti előnyben, van, aki a másikat. Sokan a szekvencia- 
diagramot szetetik, mivel az jobban kifejezi a sorrendiséget. Abban köny- 
nyű követni azt a sorrendet, amiben a dolgok végbemennek. Mások azért 
preferálják az együttműködési diagramokat, mivel ott olyan elrendezésben 
tudják felrajzolni az objektumokat, amiből látszik, hogy azok hogyan kap- 
csolódnak egymáshoz statikusan. 

Mindkét fajta interakciós diagramnak fontos jellemzője, hogy eléggé 
egyszerűek. Jól áttekinthetők bennük az üzenetek az objektumok között. 
Ugyanakkor az ilyen diagramok használatát megnehezíti, ha sok feltételes 
elágazás van bennük, vagy pedig hutkokat tartalmaznak. Hogyan étdemes 
a feltételes működést ábrázolni: 


e Az egyik megoldás az, amikor külön diagramot rajzolunk fel minden 
egyes szcenátióra nézve. 

e A másik megoldás az, amikor az üzeneteket egészítjük ki azokkal a 
feltételekkel, amelyek teljesülése esetén megy ki egy adott üzenet. 
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Az első megoldás előnye a biztonságos áttekinthetőség. Az interakciós 
diagramokat illetően általában is érdemes törekedni arra, hogy elkerüljük a 
túl bonyolult ábrázolást, mert azt már nehéz lesz átlátni. 


Mikor érdemes használni őket? 


Az interakciós diagramokat leginkább akkor étdemes használni, amikor 
több objektum együttes működését akarjuk látni, egyetlen egy use case-en 
belül. Egy ilyen diagram jól leírja az objektumok egymás közötti infotmá- 
cióáramlását, és az ennek hatására történő viselkedésüket. 

Ha egyetlen objektum működését akarjuk kiragadottan végigkövetni 
egy use case-en keresztül, akkor a legcélszerűbb az objektum állapotdiag- 
tamját felhasználni (7. fejezet). 

Ha az általános működést akarjuk követni több use case-en keresztül, 
akkor a legcélszerűbb az aktivitási diagramot alkalmazni (8. fejezet). 
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6. Csomagdiagramok 


6.1. A szoftverműködés lebontása 


A szoftvettechnológia egyik alapvető kérdése az, hogy milyen módon 
bontsunk le egy nagy rendszert kisebbekre. Ez azért fontos kérdés, mert 
ha egy tendszet túlságosan kitetrjedtté válik, akkor igen nehéz lesz áttekin- 
teni, megérteni a működését, és ugyancsak nehéz lesz ilyenkor a változta- 
tásokat is elvégezni rajta. A lebontással nyert kisebb rendszereknél ezek a 
nehézségek is jóval kisebbek lesznek. 

A ptocedurális, és ezen belül a strukturális tetvezési módszerek funkci- 
onális lebontást (functional decomposition) alkalmaznak. Ebben a megközelítés- 
ben először a teljes rendszer egészének a funkcióját veszik figyelembe, és 
utána ezt bontják szét több alfunkcióra, majd ezt követően az alfunkciókat 
bontják le további al-alfunkciókra. Az így kezelt funkciók hasonlítanak egy 
objektumorientált szoftver use case-eire, feltéve, hogy az egyes funkciókat 
összerakva valóban a teljes tendszet működése fog előállni. 

A procedurális szoftveteknél a folyamatok és az adatok szét vannak 
választva. Ebből adódóan a funkcionális lebontáson kívül még külön meg 
kell tervezni az adatstruktútát is, mégpedig úgy, hogy az összhangban le- 
gyen a funkciók együttesével. 

Az objektamorientált technológia éppen ezen a téten hozta a legna- 
gyobb változást. A folyamatok és az adatok szétválasztása eltűnt, meg- 
szűnt, a funkcionális lebontás úgyszintén megszűnt benne. Mindazonáltal 
az eredeti nagy kérdés továbbra is megmaradt: Hogyan bontsuk szét a 
teljes nagy tendszet egészét kisebb rendszerekre? 

Az egyik megoldási megközelítés az, hogy az osztályokat csopottosít- 
juk magasabb szintű egységekbe. A legtöbb OO tervezési módszer is ezt 
az elvet próbálja követni. Az UML-ben is megvan az erre irányuló csopot- 
tosítási mechanizmus. Egy-egy ilyen jellegű csopottot csozzagnak (backage) 
nevezünk. 


6.2. Függőségi viszonyok 


A csomagba való csopottosítás elve nem csak az osztályokra alkalmazha- 
tó, hanem bármilyen alkotóelemre. A csoportosítás menetére vonatkozóan 
nem állnak rendelkezésre egzakt algoritmusok, bevált módszerek. Vagyis: 
általános recept nincsen. Ehelyett intuitív, heurisztikus megoldásokat lehet 
alkalmazni. 
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Az UML-ben a leginkább elterjedt rendezési elv az ún. függőség 
(dependency). A csomagokat ábrázoló diagramokat, amelyek a függőségeket 
is kifejezik, csozagdiagramnak (backage diagram) nevezzük. Fontos megje- 
gyezni, hogy az ilyen diagramokban a függőségi kapcsolatok és a csopor- 
tosítás az osztályokra vonatkoznak. 

Szigorúan véve a csomagok és a köztük levő függőségek egy osztálydi- 
agramhoz tartozó elemek. Mondható tehát, hogy a csomagdiagram az 
osztálydiagtamnak egy bizonyos megjelenési formája. A két külön elneve- 
zés használata azért indokolt, mett a két megjelenési formát is külön cé- 
lokra érdemes használni. 

Mindezek után definiáljuk a fjggóség fogalmát. Két tetszőleges elem kö- 
zött akkor létezik fiiggóség, ha az egyik elem specifikációjában, megvalósítá- 
sában történő változtatás változást okozhat a másik elem specifikációjá- 
ban, megvalósításában. Röviden szólva, az egyik elem megváltoztatása 
kihat a másik elemre. Osztályok esetében a függőség különböző okokra 
vezethető vissza. Például: az egyik osztály üzenetet küld a másiknak; az 
egyik osztály a másik osztályt adatai részeként használja; az egyik osztály a 
másikat egy saját műveletének (metódusának) patamétereként használja 
fel. Ha például egy osztálynak megváltoztatjuk az interfészét, akkor bár- 
melyik általa küldött üzenet elveszítheti korábbi érvényességét. 

Ideális esetben csak annak kellene befolyásolnia bármelyik más osztály 
működését, ha egy osztálynak megváltoztatnánk az interfészét. A nagymé- 
tetű projekteknél általános cél, hogy minimalizáljuk a függőségeket. Ennek 
a célnak az a nyilvánvaló éttelme, hogy egy változtatás hatása minél kisebb 
körre terjedjen ki, és ezáltal minél kisebb ráfordítással lehessen a teljes 
tendszeren átvezetni a változtatásokat. 

Példaként tekintsük a 6.1. ábrát. Ezen dozén osztályok láthatók, amelyek 
egy üzleti modellt adnak ki. A modell két csomagba van csopottosítva: 
Orders (megtendelések) és Cwszozzers (ügyfelek. Mind a két csomag egy álta- 
lánosabb domén csomag tészét képezi. Az Order Capiure Application (rmmeg- 
rendelési alkalmazás) függőségben van mind a két domén csomaggal. Az 
Order Capture UI (megrendelési fogadás felhasználói interfésze) függőség- 
ben van az Order Capture Application-nel, valamint az AWT-vel (az AWT 
egy Java grafikus eszközkészlet). Az ábrán a függőséget a szaggatott vonal- 
lal megrajzolt nyilak fejezik ki. A nyíl abba az irányba mutat, amelyik elem- 
től a függőség ered. A 6.2. ábrán egy ilyen kapcsolat látható, ahol az A 
elem függőségben van B-vel, úgy, hogy A függ B-től. 
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6.1. ábra. Egy csomagdiagram 


























6.2. ábra. Függőségi kapcsolat 


Két csomag között akkor áll fenn függőség, ha bármilyen függőség létezik 
az egyik csomag bármelyik osztálya és a másik csomag bármelyik osztálya 
között. Például, ha a Mailing List Apdication (postázási lista alkalmazás) 
csomag bármelyik osztálya függőségben van a Cwszozzers (ügyfelek) csomag 
akármelyik osztályával, akkor függőség fog létezni a két, szóban forgó 
csomag között is. 

A függőségek a csomagokra nézve ez franzitívek, ami itt egy fontos sa- 
játosság. A íranzitivitás a függőség láncszerű továbbszármaztatását jelenti, a 
függőségi kapcsolatokon keresztül. Ez viszont nem feltétlenül teljesül a 
csomagdiagtamoknál, amite egy szemléltető példát ad a 6.3. ábra. Az áb- 
rán A függ B-től, és B függ C-től. Ebből a relációból viszont még nem 
következik egyértelműen, hogy A is függ C-től. Tetmészetesen, ez nincsen 
kizárva, csak nem garantálható törvényszetűen a függőségi lánc megléte A 
és C között. 
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6.3. ábra. Nem tranzitív kapcsolatok 


Egy példa a íranzitív teláció meglétére: 
, Géza magasabb, mint Péter", ,, Péter magasabb, mint Tamás". 
A fenti kettőből egyértelműen következik, hogy 


, Géza magasabb, mint Tamás", vagyis a , magasabb, mint" reláció 
tranzitív. 


Ezzel szemben a , barátja valakinek" reláció már nem tranzitív. A 
, Géza batátja Péternek", ,, Péter barátja Tamásnak? 


telációkból nem következik, hogy ,, Géza barátja Tamásnak". Lehet, hogy 
nem is ismerik egymást. Petsze azt nem lehet kizárni, hogy esetleg mégis 
barátok lennének. 

A csomagdiagramoknál pozitív sajátosság, hogy a függőségi viszony 
nem tranzitív, tehát nem terjed feltétlenül tovább. A 6.1. ábra példáján ez 
az elv a következő módon tud érvényesülni: 

Ha az Orders csomagban megváltozik egy osztály, az nem vonja maga 
után azt, hogy az Order Capiure UI csomagot meg kellene változtatni. Amit 
maga után von, az mindössze annyi, hogy csak azt kell megvizsgálni, hogy 
az Order Captiure Application csomagnál szükség van-e a változtatásra. 

Az Order Capiure UI csomagot csak akkor kellene megváltoztatni, ha az 
Order Capture Application csomag interfészében történt volna változtatás. Vé- 
gül is, itt az látható, hogy az Order Capiure Application csomag mintegy vé- 
dőfalként szerepelt az Order Captuwre UI csomag felé, és ezáltal megóvta azt 
az Orders csomag változásának hatásától, következményeitől. 

Ez az a működési elv, amit a klasszikus séfeg szervezési megoldás is al- 
kalmaz. Ebben a megoldásban az egymással nem határos szoftverrétegek 
önállóan változtathatók, és nem hat ki rájuk a nem-határos téteg szoftver- 
jében végrehajtott változtatás. Mint ismetetes, tipikusan ily szervezésűek 
például az operációs rendszerek. 

Az egyes OO programozási nyelvek különböző módon segítik elő, te- 
szik lehetővé a változtatási hatások továbbterjedésének gátlását, megakadá- 
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lyozását. Ez erősen összefügg azzal, hogy egy adott 00-nyelv milyen látha- 
tóságot biztosít egy osztály esetében a többi osztály számára. Vagyis, a töb- 
bi osztály mit lát belőle, és mit tud befolyásolni benne, másrészt a külön- 
böző osztályok milyen mértékben képesek egymás működését látni, ellen- 
őrizni, befolyásolni. Tehát egy programozási nyelvtől függ az, hogy meny- 
nyire engedi meg azt, hogy az osztályok egymással össze tudjanak fonódni 
a működésükben. Ebben a tekintetben a Ct- nyelv jóval nagyobb látható- 
ságot, azaz tranzitivitást enged meg, mint például a Java nyelv. 

A csomagok önmagukban véve nem adnak támpontot abban, hogy 
miként tudjuk csökkenteni a függőségeket a szoftverünkben. Amiben a 
segítségünkre vannak, az abban áll, hogy látni tudjuk belőlük, hol vannak a 
függőségek. Ezeket a függőségeket csak úgy tudjuk megszüntetni vagy 
csökkenteni, ha tisztában vagyunk azzal, hogy hol vannak ilyenek. A cso- 
magdiagramok kitűnő segédeszközök arta, hogy a teljes szoftvertendszer 
struktúrája felett áttekintésünk legyen, és abba célszerűen be tudjunk avat- 
kozni, azt át tudjuk szervezni, alakítani. 


6.3. Kibővítések a csomagdiagramban 


A csomagdiagramok további lehetőségeket is tartalmaznak. A 6.4. ábra 
ilyen kibővítéseket tüntet fel a 6.1. ábrához képest. 

Az egyik bővítés az, hogy egy közös Dozain nevű csomagba lett bele- 
rakva az Orders és a Cusftomers nevű csomag. Ezáltal a függőséget csak erre 
a magasabb szintű csomagra kell értelmezni, a benne levő elemekre vonat- 
kozó szétbontott függőségek helyett. Az ilyen jellegű módosítás hasznos 
lehet az elemzés továbbvitelében. Itt az Order Cabiure Application a teljes 
Domain csomagtól van függésben, míg a Mazling List Application csak a 
Customers csomagtól van függőben. 

A másik bővítés a Common (közös) elnevezésű csomag megjelenítése. 
Ez a csomag a íg/obaly megjelölést kapta, ami azt jelenti, hogy a diagram 
mindegyik másik csomagja függésben van a Common csomagtól. Ebben 
például benne van a Money (pénz) nevű osztály, amit mindegyik csomag 
közösen használ. Mindehhez nem is kellett nyilakat rajzolni. 

A harmadik bővítés az fabszracty megjelölésű Database Interface (adatbá- 
Zis-interfész) csomag, ami egy általános interfész csomag. Ez nem végle- 
ges, csak egy átmeneti csomag, aminek a tetvezésben van szerepe. Itt két 
adatbázis-interfész használatának a lehetősége szerepel: az Oracle Interface 
és a Sybase Interface. A terv véglegesítése után az abszttakt, általános csomag 
helyébe a konktét, specifikus intetfészcsomag fog bekerülni. 
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6.4. ábra. Kibővített csornagdiagtam 


A függőségi sttuktúrában előfordulhat, hogy az egymáshoz kapcsolódó 
függőségek egy zárt kött írnak le. Az ilyen kört cik/usnak vagy buroknak 
nevezzük. A jelenséget a 6.5. ábrán szemléltetjük. 

Általánosan követendő szabályként lehet kimondani, hogy törekedni 
kell a ciklusok elkerülésére, vagy megszüntetésére. Ez nem mindig oldható 
meg, de ha nem lehet is megszüntetni mindegyik ciklust, akkor is minimá- 
lis számúra kell csökkenteni őket. Az is egy jó elv, hogy ha nem tudunk 
megszüntetni egy ciklust, akkor próbáljuk meg a ciklusban levő csomago- 
kat egy nagyobb, mindegyiket tartalmazó csomagba beleépíteni. 
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6.5. ábra. Függőségi ciklus 


6.4. Használati szempontok 


A csomagdiagtamokat érdemes akkor is használni, amikor egy meglevő 
szoftver átalakítására van szükség. Ilyenkor meghatározzuk a meglevő 
osztályok között fennálló függőségeket, ezután az osztályokat csomagokba 
osztjuk be, és elemezzük a csomagok közötti függőségeket. Az elemzés 
után átrendezést (refactoring, lásd a 2. fejezetben) hajtunk végre, azzal a céllal, 
hogy csökkentsük a függőségek számát. 

A csomagdiagtamok használata feltétlenül szükséges és hasznos a nagy 
projektek esetében, ahol igen sok osztály szerepel a tetvben. De kisebb 
méretű osztálydiagramok esetén is megértheti, ha támaszkodunk tájuk. 

Mindig törekedni kell a függőségek számának minimalizálására, bár er- 
re általánosan alkalmazható algoritmus, módszer egyelőte nem létezik. 
Csak intuitív, heurisztikus elvekre lehet támaszkodni. A jó megoldás eléré- 
sében sok függ az egyéni ügyességtől és tapasztalattól. 

A csomagokat igen jól lehet felhasználni a szoftvet tesztelése során. 
Ehhez kétféle megközelítést étdemes alkalmazni: 


e Először az egyes osztályokhoz készítsünk, írjunk teszteket. 
e A második menetben az egyes csomagokhoz, mint magasabb szintű 
egységekhez készítsük el és hajtsuk végre a teszteket. 
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7. Állapotmodellezés 


A rendszetben feltárt objektumokat működésük során különböző hatások 
érik, amely hatásokra adott módon reagálnak, és eközben megváltozhat 
viselkedésük. Az objektumok tehát a külső hatások eredményeként meg- 
változtatják állapotukat, valamint hatnak környezetükre, amivel a környe- 
zetükben levő más objektumok állapotváltozását idézhetik elő. 

A változó működést produkáló objektumok viselkedésének leírása és 
az állapotuk részletes definiálása fontos feladat. Különösen a tervezés és 
az implementáció szakaszában van ennek nagy jelentősége, amikor a rend- 
szerünk procedurális részeit akarjuk megtervezni. Lesznek a modellben 
olyan osztályok, amelyeken a művelet végrehajtása attól függ, hogy az ob- 
jektum milyen állapotban van. 

Az objektumok állapota az attribútumaikban lesz eltárolva. Az álla- 
potmodellezés segít az attribútum-lista végleges meghatározásában. Osztá- 
lyokat leíró attribútumokat már az elemzés korai szakaszában definiálunk. 
Az elemzés során felállított lista azonban számos olyan attribútum- 
jellemzőt is tartalmaz, amelyekre a modellben valójában nincs szükség. Az 
állapotmodellezés segít a felesleges jellemzők kiszűrésében. 

Az objektumok viselkedésének modellezésére az állapotátmeneti diag- 
tamok szolgálnak. Az állapotátmeneti diagramok ábrázolására a módszer- 
tanok különböző megoldásokat javasolnak. Az egyes megoldások alapve- 
tően szemantikájukban különböznek egymástól. Az UML állapotátmeneti 
diagramja a David Harel" által kidolgozott módszer logikáján alapszik. 


7.1. Az állapotátmeneti diagram 


Az állapotátmeneti diagram az objektumok dinamikus viselkedésének leításá- 
ta szolgáló eszköz. Segítségével egy-egy objektumot elemezhetünk, arra 
keresve a választ, hogy az objektum az események hatására hogyan változ- 
tatja meg a belső állapotát, valamint az események hatására milyen üzene- 
teket küld a többi objektum számára. Egy állapotdiagramot mindig egy 
osztályobjektumhoz készítünk, ill. egy magasabb szintű diagtam pontosítá- 
saként. A fejlesztés során csak az intenzíven dinamikus (változó) viselke- 
désű objektumok állapotátmeneteit érdemes modellezni. A gyakotlatban a 





7 A David Harel által kidolgozott állapotleírást az 0O0-módszertanok közül elsőként az 
OMT (Object Modeling Technigue) módszettan alkalmazta, majd 1994-ben Booch is 
beépítette módszettanába. 
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legtöbb osztályhoz nem készül állapotátmeneti diagram, mert azok a tend- 
szetben csak kisegítő ún. utility osztályok. 

Az állapotátmenetet modellező diagram szerepét megfogalmazhatjuk 
tágabb és szűkebb értelemben: 


e Tágabb értelemben: 
— a tendszer dinamikus nézetét jellemző technika. 
— az állapotátmeneti diagramokkal leírható egy rendszer viselkedése. 
e Szűkebb megközelítésben: egyetlen osztályhoz kapcsolódó fogalom, 
amely bemutatja az osztály konktét objektumának élettartama (a tend- 
szerben levő) alatt mutatott viselkedését, vagyis: 
— azokat a lehetséges állapotokat, amelyekbe az objektum kerül, jut, és 
- ahogy az objektum állapota változik (állapotátmenet) az őt étő 
események hatására. 


Az állapotok leírásában az eseménykövetési diagramok is segítenek. Az 
állapotok feltétképezéséhez ki kell gyűjteni az adott osztály objektumait 
teprezentáló függőleges vonalakat (életvonal — lifeline), a kapott és küldött 
üzeneteket jelölő nyilakkal együtt. A kapott üzenetek forrása és a küldött 
üzenetek célja az állapotmodell szempontjából lényegtelen. Egyetlen ese- 
ménykövetési diagramrészletből kell kiindulni, végig kell nézni az objek- 
tumhoz étkező, és az objektumot elhagyó üzeneteket. Az állapotok két 
esemény között írják le az objektumot. Ha két egymást követő állapot 
között az objektum kívülről kap üzenetet, akkor ezt az eseményt kell meg- 
adni az állapotátmenet eseményeként. Amennyiben a két állapot között az 
objektum küld üzenetet, az üzenet elküldését az átmenet során elvégzendő 
akcióként kell megadni. Vannak esetek, amikor az eseménykövetési diag- 
tam ciklusokat tartalmaz. Ilyenkor a bejárt állapotokat csak egyszer kell 
léttehozni, és az állapotátmeneteket úgy kell kialakítani, hogy a ciklus vé- 
gén az objektum újra a ciklus elején lévő állapotba kerüljön. 


7.2. Az objektum állapota 


Az objektumok a valós dolgokat leíró elemek a rendszerben. A valós dol- 
gokhoz hasonlóan az objektumoknak is van létük, mindegyik valamikor, 
valaminek a hatására létrejön, egy bizonyos ideig létezik, majd megszűnik. 
Az objektumok kommunikálnak egymással. A kommunikáció során az 
objektum detektálja az őt ért eseményeket, illetve reagál az eseményekre. 
Egy esemény hatására az objektum állapota megváltozhat. Az objektumok 
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a felvett állapotokat csak véges ideig tartják, ez alatt az idő alatt az objek- 
tum az adott állapotban van. Egy objektum pillanatnyi állapotát jellemzői- 
nek (az adott pillanatban felvett tulajdonságértékek, és az objektumnak a 
környezetében levő más objektumokkal megvalósított kapcsolatai pilla- 
natnyi értékei határozzák meg. 

Az állapot 

e Az állapot az objektum életének egy szakaszát jellemzi. Az objektum 
pillanatnyi állapota alatt az adott időpontban felvett attribútum- 
értékeinek és aktuális kapcsolatainak együttes halmazát értjük, ezek 
alapján határozhatjuk meg azt. 

e Az állapot két esemény közötti időtartamig érvényes, egy nem nulla 
hosszú időintetvallum, ami alatt az objektum valamely esemény bekö- 
vetkezését várja, vagy ami alatt az objektum folyamatosan végrehajt 
egy akciót. 

e Egy adott állapotban levő objektum ugyanatta az eseményre mindig 
ugyanúgy reagál, vagyis ugyanazt az akciósotozatot hajtja végte. 

e Az állapotokat lekerekített téglalapok szimbolizálják. 

e Az állapotok közötti átmeneteket nyilak jelölik. 


Az objektumok viselkedését leíró állapotátmeneti diagram pontosan egy 
kiinduló állapotot, egy vagy több végállapotot, valamint tetszőleges számú 
belső állapotot modellez. A kiinduló állapotot egy teli kör szimbolizálja, a 
belső állapotokat lekerekített téglalapok jelölik. A végállapot/végálla- 
potokat egy üres körben teli kör ábrázolja. Az állapotokat teprezentáló 
téglalap két tészre osztható. A felső tészben az állapotra utaló név szere- 
pel, az alsó tekesz az állapothoz tartozó belső állapotátmenetet jelöli. Itt 
tevékenységek megadására van lehetőség, amelyeket az objektumok kü- 
lönböző üzenetek (események) hatására hajtanak végre, miközben állapo- 
tuk nem változik. 


7.3. Az állapotátmenet 


Az állapotmodellezés témakötben az állapot mellett másik fontos fogalom 
az állapotátmenet értelmezése. Az átmenet az objektum válasza, reakciója 
egy külső eseményre. Az objektumokat életük sotán hatások, ún. esemé- 
nyek érik. Az objektumok a bekövetkezett eseményeket érzékelik. Az 
események hatására állapotuk megváltozhat, vagyis az aktuális állapotból 
másik állapotba kerülhetnek. Az állapotátmenetet tehát egy esemény váltja 
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ki. Az állapotátmenet általában eljáráshívással jár együtt, vagyis valamilyen 
tevékenység végrehajtásával. Az állapotátmenetnek két típusáról beszé- 
lünk: 


e külső állapotátmenet: Az objektum állapotai között értelmezzük, az 
állapotokat összekötő nyíllal jelöljük. Az aktuális állapotból másik álla- 
potba vezet. Eljáráshívás vagy tötténik, vagy nem. 

e belső állapotátmenet: Az objektum egy adott állapotában értelmezzük. 
Eljáráshívással ját együtt anélkül, hogy az objektum állapota megvál- 
tozna. A belső átmenetet az állapot alsó rekeszében adjuk meg. 


Az állapotátmenet vezethet az aktuális állapotba is, azaz az állapotátmenet 
diagram szintjén az állapotátmenet nem feltétlenül jár együtt állapotválto- 
zással. 

Az állapotátmenethez megadhatók pluszjellemzők. Megadásuk opcio- 
nális: 


e Esemény (trigger vagy event): Az átmenet a kiváltó esemény hatására 
következik be. Az esemény egyatánt jöhet kívülről vagy belülről. 

e Feltétel (guard): Az átmenethez tartozhat feltétel. A feltétel egy logikai 
kifejezés az objektum attribútumok és üzenet-paraméterek felhasználá- 
sával. Az átmenet csak akkor következik be, ha a megadott feltétel 
igaz. A feltétel megadható az OCL" segítségével. 

e Akció (action): Az objektum által végzett elemi műveletek, amik az 
átmenetkor hajtódnak végte. 

e  Szintaxisa: esemény [feltétel] / akció — Event [condition] / action. 


A továbbiakban tekintsük meg az állapotátmenethez hozzárendelhető 
pluszjellemzőket egyenként, részletesebben! 


7.3.1. Esemény 

e Esemény vagy üzenet: egy objektumnak egy másik objektumra történő 
hatása. Az objektum adott állapotából adott esemény hatására másik, 
új állapotba kerülhet. 

e Az állapotátmenetet események idézik elő. 

e Az esemény egyetlen időpillanathoz és nem időtartamhoz kapcsolódik. 
Elemi dolog, nem szakítható meg. 





18 Object Constraint Languge 
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e Ha egy átmenethez nincs esemény megadva, akkor esemény nélküli 
állapotváltásról beszélünk. Ekkor az objektum az állapothoz rendelt 
tevékenységet végrehajtva automatikusan a következő állapotba kerül. 

e "Nem minden esemény okoz feltétlenül állapotátmenetet. 

e A modellben le nem kezelt események az objektum számára elvésznek. 


7.3.2. Feltétel 


e A feltétel (őrszem — guard/ condition) az állapotátmenet feltétele. 

e A feltétel egy megadható logikai kifejezés. A feltétel értékének az álla- 
potátmenethez igaznak kell lenni. 

e A feltétel maga is az objektum állapotára utal, de ezt nem jelöljük kü- 
lön névvel. 

e A feltételt szögletes zárójelek [feltétel] között az esemény neve után 
adjuk meg. 

e Az objektum egy adott állapotából vagy egy esemény hatására, vagy 
automatikus átmenettel csak akkor kerül az átmenet által meghatáro- 
zott állapotba, ha teljesíti az őrszemként megadott feltételt, vagyis ha 
az átmenet feltételhez van kötve, az állapotváltozás csak az esemény 
bekövetkezése és a feltétel igaz értékének bekövetkezése esetén tötté- 
nik meg. 

e Ha a feltétel egy esemény nélküli átmenethez tattozik, akkor az átme- 
net a feltétel igazzá válásakor rögtön végrehajtódik. 

e Afeltétel hamis éttéke esetén az objektum állapota nem változik. 


7.3.3. Tevékenységek, akciók 


Az állapotokhoz megadhatók végrehajtandó tevékenységek. Az objektu- 
mok meghatározott ideig vannak egy adott állapotban, eközben különbö- 
ző tevékenységeket végezhetnek. Az akció az objektum által végzett elemi 
műveletek halmaza, amiket az átmenetkor kell végrehajtani. A tevékeny- 
ségek és az akciók a tendszer működtetése során végrehajtandó feladatok, 
műveletek (eljárások), amelyek az objektum metódusaként implementál- 
hatók. 

Az UML igazán nem tesz különbséget a két fogalom között, mégis le- 
het következtetni, hogy elemi műveletről (akció) vagy tevékenységről van 
szó (lásd 7.1. táblázat). Például az állapothoz tartozó tevékenységet félbe- 
szakíthatja egy külső esemény (azonban a kimeneti tevékenység ekkor is 
végrehajtódik), az akció nem szakítható félbe, mert nem rendelkezik idő- 
tattammal. 
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7.1. táblázat. Tevékenységek, akciók 











Tevékenységek Akciók 

A tevékenységek végrehajtási idővel ] Az akciók pillanatnyi műveletek: 
rendelkező műveletek: e Az objektum által végzett elemi 
e Elemi műveletekből álló tevé- műveletek. 

kenységek. e A  funkcióhieratchia legalsó 
e  Összetettebbek, további lépé- szintjén elhelyezkedő elemi mű- 

sekre bonthatók. veletek, ún. atomi műveletek — 
e "Események által megszakítható további lépésekre nem bontha- 

tevékenységek a végrehajtás fo- tók. 

lyamatában. e Nem szakíthatók meg, nem 
e Az elemi műveletekből (akciók) rendelünk hozzájuk időtartamot 

álló tevékenységek elvégzéséhez] — — ezért az átmenethez kapcsol- 

meghatározott időre van szük- hatók. 

ség — ezért az állapotokhoz]e pl. számítási műveletek, objek- 

kapcsolódnak. tum manipulálására vonatkozó 

kérések. 











Tevékenységek (activities) 

e A tevékenység állapothoz tartozó művelet, aminek végrehajtása időt 
vesz igénybe, tehát a tevékenységekhez időtartam tartozik. 

e A tevékenységek végrehajtása alatt az objektum állapota nem változik. 

e A tevékenységekhez kapcsolhatók belépési pontok, kilépési akciók. 


A tendszetben történnek események, amelyek nem okoznak közvetlen 
állapotváltozást, vagyis hatásukra az objektum az adott állapotban marad 
(belső állapotátmenet). Az események általában valamilyen tevékenységek, 
akciók végrehajtásával járnak együtt. Az állapotokkal kapcsolatban többfé- 
le akció különböztethető meg, egy állapothoz rendelhető: 


e bemeneti akció — entry action. 

e kimeneti akció — exit action. 

e belső akció — internal action. 

e belső állapotátmenet — internal state-transition. 
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Bemeneti akció 


e Az eníry/ jelölés után adható meg. 

e A bemeneti akció az állapotba való belépéskor végtehajtandó elemi 
utasítást definiálja. 

e Azt az esetet rövidíti, amikor az állapotba vezető minden átmenet ese- 
tén azonos tevékenységet akarunk végrehajtani. 


Kimeneti akció 


e Az exit/ jelölés után kell megadni. 

e A wkimeneti akció az állapot elhagyásakor végrehajtandó elemi utasítást 
definiálja. 

e Azt az esetet rövidíti, amikor az állapotból kivezető minden átmenet 
esetén azonos tevékenységet akarunk végrehajtani. 


Belső akció 


e Az objektum adott állapotban tevékenységeket végezhet. A végrehaj- 
tandó tevékenységeket a do prefix után kell megadni. 

e A tevékenység végrehajtásához időre van szükség, ez alatt az idő alatt 
az objektum állapota nem változik. 


Belső állapotátmenet 


e A belső átmenetek azok, amikor az állapotból kiinduló, az eseménnyel 
círnkézett él ugyanabba az állapotba tér vissza, de ekkor nem hajtódik 
végre sem kimeneti, sem bemeneti akció, mivel az objektum ugyanab- 
ban az állapotban maradt. 

e A belső átmenet egy adott esemény hatására kerül végtehajtásta. Az 
esemény egy akciót vált ki, amit végre kell hajtani anélkül, hogy az ob- 
jektum állapota megváltozna. 

e Belső átmenet megadásakor megadjuk az esemény nevét, paraméterlis- 
tát kerek zárójelekben, szögletes zárójelben definiáljuk a feltételt, a fel- 
tételt követő perjel után a végrehajtandó akció nevét: event (arguments) 
[condition] / action. 
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Az Otder objektum állapotai 


Az Otdet objektum lehetséges állapotait az alábbi állapotátmenet diagram 
szemlélteti. 


kezdő 
állapot ; 


/ get fret item 
tevékenység 


[ not all items checked ] / 
get next item 








ítem rscsivsdi[ al items aailabis ] 









[ all Items checkedő-6some items not in stock ] delvered 


állapotátmenet 
3 (  déltered 
állapot — 


A diagram mutatja a kezdő állapotot (statt point): az objektum létrejötte- 
kor automatikusan a kezdő állapotba lép. A kiindulási/kezdő ázeneibez 
csak egy jellemző tartozik, a,,/ get fitst item"? akció. Ez az átmenetkor 


Item receive d[ some Items 
not in stock ] 


végrehajtandó akció, elsőként ezt az a£cióf kell végrehajtani a checking 
állapotba való belépéshez. 


/ get first item 


checking 
do: check item . 
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A checking állapotból három átmenet látható. Mindhátom átmenethez 
feltétel, őtszem tartozik. 







feltétel 






( not all items phecked ] / 
get next item 


íg checking all items checked8.8-all items available ] 
do: check item 





[ all items checkedő.ásoms items not in stock ] átmenet 


Egy adott állapotból csak egy átmenet következhet. A példában a checking 
állapotból három átmenet látható: 


e  Rendeléskor ellenőrizni kell, hogy létező tetmékről van-e szó: checking 
állapot (A cég kínálatában mindig újabb és újabb termékek jelennek, 
bizonyos termékek gyártása pedig megszűnhet). Az ellenőrzés egészen 
addig tart, amíg a rendeléshez tartozó összes terméket le nem ellen- 
őrizte a tendszer. A modellben ezt a /get next item akció és a checking 
állapotba való visszatérés mutatja. 

e Ha minden terméket leellenőriztünk, de azok közül nem mindegyik 
van raktáron az adott mennyiségben, akkor az objektum a waiting álla- 
potba kerül. 

e Ha minden terméket leellenőriztünk, és azok mindegyike raktáron is 
van, az objektum a dispatching (a tendelés feladása) állapotba kerül. 
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y [ all items checked8.8. 
; all items available 
[not s next tariiik / checking ] s dispatching 
do: check item do: initiate delivery 


[ all items checked88some items not in stock ] 





item received[ some items Vvy 


not in stock] via 


Az Otder objektum a checking állapotban , check item? tevékenységet 
végez. 


checking 





do: check item 


A waiting állapot jellemzése: 

e A waiting állapothoz nincsenek megadva végrehajtandó tevékenységek. 

e Az adott Otdetr objektum a waiting állapotban tartózkodik egy ese- 
mény bekövetkezésére vátva. 

e A waiting állapotból két kimenő állapotátmenet mindegyikéhez az item 
received esemény tartozik, ami azt jelenti, hogy az order addig várt, 
amíg nem észleli az eseményt, vagyis az esemény bekövetkezésére vár. 

e Az Otder kiéttékeli az átmeneten levő feltételeket, majd végtehajtja a 
megfelelő tranzakciót: 

— vagy visszamegy a waiting állapotba, 
— vagy az otder a feltételek kiértékelésének eredményeként a dis- 
patching állapotba kerül. 
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dispatchirg 
do: initiate delivery 
7 


item received all items available ] 


item received[ some items y 
not in stock ] vzÜ; i 
A dispatcbing állapot 


e A dispatching állapotban meg van adva egy végrehajtandó tevékeny- 
ség, amit a do prefix jelez. Az objektum a dispatching állapotban 
initiate delivery — szállítás elindítása tevékenységet végez. 

e Létezik egy feltétel nélküli átmenet a delivered eseménnyel triggerelve. 
Ez azt jelzi, hogy az átmenet feltétel nélkül mindig bekövetkezik, ami- 
kor a delivered esemény bekövetkezik, azonban az átmenet nem kö- 
vetkezik be automatikusan, ha a tevékenység befejeződött. 

e Ha az initiate delivery tevékenység befejeződött, az adott order egé- 
szen addig marad a dispatching állapotban, amíg a delivered esemény 
be nem következik. 


dispatching 
do: initiate delivery 


delivered 


N 


delivered 
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A cancelled átmenet 


e A rendszernek lehetőséget kell adni arra, hogy a rendelési folyamat 
bármely pontjában töröljük a megadott rendelést, mielőtt a termékek 
szállításra kerülnének. 

e A modellben ezt úgy oldjuk meg, hogy mindegyik állapotból: checking, 
waiting, dispatching biztosítunk egymástól elkülönített átmeneteket a 
cancelled állapotba. 








/ get first item 
Vvy [ all items checked8.8. 
[ not all items checked ] / EhEckiT all items available ] JzsztéNn 
get next item e EROS S EBPSÉTÉEL a 
do: check item do: initiate delivery 
Z7/ 
item received 
[ all items checkedg.8. I all items available ] 
some items not in stock ] 
delivered 
cancelled 
cancelled 
item received[ some items Vv 
not in stock] waiting NI 
delivered 
cancelled 
XV 
cancelled 





Az állapotátmeneti diagram sok esetben bonyolulttá válhat. A diagtamot 
finomíthatjuk, aminek etedményeként beszélhetünk: 


e  állabotbierarcbia viszonytól: öröklődési viszony definiálható az állapotok 
között. 

e konkurrens viselkedésről: páthuzamos állapotfolyamok (szálak) egyidejű 
végrehajtását jelenti. 

e emlékező állapotról: megszakítás esetén a legutolsó aktív állapotba való 
visszatérést biztosítja. 
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7.4. Állapothierarchia - Szuperállapot, 
szubállapotok 


Ha vannak a diagramban olyan állapotok, amelyek logikailag egy nagyobb 
egységbe összefoghatók, akkor ezeket az összetartozó állapotokat étdemes 
egy ún. szuperállapotba kiemelni, és ebben az egységben kezelni. A logi- 
kailag együttkezelt állapotokat alállapotoknak vagy szubállapotoknak ne- 
vezzük, a léttejött új állapot a szuperállapot. A szubállapotok és a kiemelés 
eredményeként létrejött szuperállapot közötti viszony egyfajta öröklődési 
hierarchiát eredményez. Az alállapotok öröklik a szuperállapot átmeneteit 
(a példában a cawce/ed átmenetet), ha azt nem definiálják át. Továbbá egy 
szuperállapotban levő objektum lehet a szubállapotok bármelyikében. 





Szuper- és szubállapotok 

Az Otder objektum a checking, waiting, dispatching állapotok mindegyiké- 
ből a cancelled esemény hatására cancelled állapotba kerülhet. Ebben az 
esetben érdemes a checking, waiting, dispatching állapotokat egy nagyobb 
egységbe összefogni. Érdemes létrehozni a három állapotnak (szubálla- 
potok) egy szuperállapotát, majd ebből megrajzolni egyetlen átmenetet a 


/ get first iteractive 


y [ all items checked88 


; all items available 
[notall items checked ]/ checking ] s dispatching 
get next item 





do: checkitem do: initiate delivery; 
T 


VV delivered 
waiting 





[A V 


cancelled delivered 
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cancelled állapotba. A modellben a szuperállapotnak az active nevet adtuk, 
jelentésében megkülönböztetve azt a cancelled állapottól. A checking, wait- 
ing, dispatching szubállapotok öröklik az active szupetrállapot cancelled 
átmenetét. Az active szupetállapotban levő otdet objektum a szubállapotok 
bármelyikében lehet, egyidejűleg azonban csak az egyik szubállapotban. 





A szubállapotok egy meghatátozott szuperállapoton belül vagy: 


e  szekvenciálisan követik egymást: 
— az állapotok diszjunkt állapotok, 
— a szupetállapotot egy adott időpontban az alállapotok közül mindig 
csak egy határozza meg, vagy 
e párhuzamos végrehajtásúak — konkuttens szub-állapotok. 


7.5. Konkurrens állapotdiagram 


e Olyan műveletsorok (állapotfolyamok) végrehajtását jelenti, amelyek 
párhuzamosan végezhetők egymással. 

e A párhuzamos állapotfolyamok mindegyikének külön állapota van — az 
egy szuperállapotba zárt, konkutrens állapotgépeknek saját induló és 
végállapotaik vannak. 

e A szuperállapot akkor következik be, amikor a benne definiált összes 
párhuzamos állapotfolyam befejeződik, vagyis eléri a végállapotot — ha 
valamelyik szál előbb fejeződik be, az vár. 

e A konkurrens állapotmodellezés hasznos, ha egy objektumnak egy- 
mástól független viselkedéscsopottjait akarjuk leírni. 


A modellben törekedjünk minél kevesebb konkurrens szubállapot kialakí- 
tására. Ha túl bonyolult egy objektumhoz tattozó konkurrens állapotdiag- 
tam, érdemes az objektumot további objektumokta szétszedni. 





Konkutrtrens állapotdiagram 

A megrendelés során ellenőrizni kell a fizetőképességet, amit a modellben 
a Payment authorizing (fizetésengedélyezés) állapotátmenet diagrammal 
modellezünk. A diagram értelmezése: 
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e Az Otder objektum az authorzing állapotban check payment tevé- 
kenység hajt végre. 

e A tevékenység egy signal-lal fejeződik be, ami jelzi, hogy a payment 
rendben van-e. 

e Ha a payment rendben: OK, a feltétel értéke igaz, akkor az adott order 
objektum addig vár az authotized állapotban, amíg a deliveted ese- 
mény be nem következik. 

e Abban az esetben, ha a feltétel értéke hamis, az objektum a rejected 
állapotba kerül. 


authorizing  [ Payment not OK] 
! - 
do: check payment 


rejected 





[ payment OK] 
V 


authorized 





V 
delivered 


A rendszerben definiált Order állapotai: 


e  egytészt a rendelési tételek eléthetőségén alapulnak, 


e másrészt léteznek olyan állapotok is, amelyek a fizetés engedélyezésén 
alapulnak. 


Az Otder viselkedésének modellezésekor két állapotfolyamot azonosítot- 
tunk. Az egyik szál a tetmékekre vonatkozó adatokat vizsgálja, a másik 
szál a likviditási vonalat ellenőtzi. 
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waiting — cancelled 


27 ME Est 
26, A 
6 s checking - dispatching s e 


Ée—- CEZ EK ENEK ÉS ÉG ES EL SEK TE TEST lete KEST EE Let s delivered 


€0— authorizing s authorized e 


s rejected 


A konkuttens állapotátmenet diagramban: 


e ha az authorizing állapot check payment tevékenysége sikeresen befe- 
jeződött, az objektum a checking és az authorized állapotba kerül — 
párhuzamos végtrehajtású szálak. 

e Az objektum a párhuzamos folyamok bármely állapotából cancelled 
állapotba kerülhet. 

e A páthuzamos szálak mindegyikének befejeződése után a műveletsor 
kilép a szuperállapotból és a végtehajtás ismét egy ágban fog folyta- 
tódni. 





Eeőllr 1 


7.6. Emlékező állapot 


Az emlékező állapot (bistory state) különleges állapot. Emlékszik atta, hogy 
melyik alállapotból terminált, és képes atra, hogy az állapotba való újabb 
belépéskor ugyanabba az állapotba kerüljön. Az emlékező állapot a leg- 
utolsó aktív állapotkonfigurációt tárolja. A 7.1. ábra emlékező állapotot is 
tartalmazó állapotátmenet diagramot szemléltet. 
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6-7 - megszakítás 


Vg 
újrakezdés 


7.1. ábra. Emlékező állapot 














Az állapotmodellezés során az objektumok viselkedésének, és ez által a 
tendszer viselkedésének leírására van lehetőség. Az objektumok életük 
alatt különböző állapotokba kerülhetnek, és ott különféle feladatokat, te- 
vékenységeket végezhetnek. Az állapotokat, az állapot változást kiváltó 
eseményeket, azok sajátosságait az állapotátmeneti diagramban foglaljuk 
össze. Az állapotátmeneti diagram igazán hasznos aszinkton történések 
leírására. Hatékony eszköz az osztály attribútumainak és műveleteinek 
meghatátrozáskor. Az állapotmodellezés nagy segítséget jelent az egyes 
metódusok kódolásakot is. 


7.7. Objektumok tesztelése állapotdiagram alapján 


A rendelkezésre álló állapotdiagtamokat jól fel tudjuk használni az objek- 
tumok működésének vizsgálatakor, vagyis a teszteléskor. A tesztelés célja 
ilyen esetben az állapotdiagram összes állapotának a bejárása, mástészt 
pedig több lehetséges kombinációjú állapotbejárás kivitelezése. A külön- 
böző állapotbejárások ugyanis különböző működési hibák felfedésére le- 
hetnek alkalmasak. 

A 7.2. ábrán egy állapotdiagtamot látunk, ami absztrakt ábrázolásban 
egy irányított gráf, öt állapottal. Az állapotokat nagybetűvel jelöltük, az 
átmeneteket mutató éleken pedig kisbetűket tüntettünk fel a vezétlő ese- 
mények jelölésére. Például: az f esemény hatására az objektum az E álla- 
potból a D állapotba jut át. 
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S 


7.2. ábra. Állapotátmeneti diagram 


A bejárások által képviselt tesztek közül az alábbiakban mutatunk be hár- 
mat. Feltételezve, hogy az A állapotból indulunk ki, a következő esemény- 
sorozatokat írjuk elő: 


TI: a-b-e-c-f-g-h-d-f-i 
Ez egy teljes bejárás, ami az összes állapotot magában foglalja. 
T2: a—-a-—-c-f-g-h-h-h-d-f-g-e-c-f-i 
Ez egy másik teljes bejárás, ami ismétléseket is tartalmaz. 
T3: b-h-e-c-f-g-h-d-f-g-b-a-a 


Ez egy nem teljes bejárás, ismétlésekkel. 
Mindehhez még annyit fűzünk, hogy a tesztsorozatokat nem csak az A 
állapotból kiindulva tervezhetjük meg. 
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8. Aktivitási dijagramok 


8.1. Folyamatok, tevékenységek leírása 


A mérnöki világban és az informatikában nagyon sokszor van szükség 
arra, hogy működési folyamatokat írjunk le, tevékenységek menetét mutas- 
suk be. Erre a célra az UML-ben az ún. akzivitási diagramok vagy tevékenységi 
diagramok szolgálnak. Angol elnevezésük: aczivity diagram. 

Az aktivitási diagramok kialakulásának számos előzménye volt. Ese- 
ménydiagramok, folyamatábrák, különböző állapotmodellezési megoldá- 
sok, valamint az ún. Perri-hálók stb., amelyek mindegyike valamilyen fot- 
mában folyamatok leírására volt alkalmas. Ezek a diagramok különösen 
akkor használhatók jól, amikor munkafolyamatok megjelenítésére van 
szükség, vagy amikor egymással párhuzamosan, vagyis egyidejűleg futó 
folyamatokat kell ábrázolni. Az UML nyelvben definiált aktivitási diagram 
is ilyen célokra alkalmas. Ebben a központi szerepet játszó szimbólum az 
aktivitáshoz  (tevékenységbez) tattozik. Ábrázolása a 8.1. ábrán látható. A 
szimbólumban a mindenkori konkrét tevékenység megnevezése szerepel. 


Tevékenység 


8.1. ábra. A tevékenység szimbóluma 


Koncepcionális megközelítésben a tevékenység egy bizonyos feladat, amit 
el kell végezni, vagy egy személynek, vagy pedig egy számítógépnek. 
Specifikációs megközelítésben, vagy implementációs megközelítésben 
a tevékenység egy művelet vagy metódus egy osztályon belül. 
A tevékenységek egymást követik, kapcsolódhatnak egymáshoz, a kap- 
csolatokat nyíllal ellátott összekötő vonalak jelölik. A 8.2. ábrán egy olyan 
aktivitási diagramot láthatunk, ami egy italkiadó automata használatát mu- 
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tatja be. Az automata vagy kávét főz, vagy hideg kólát ad ki, a kiindulási 
tevékenység (Iia/ keresése), valamint a többi kapcsolódó tevékenység, műve- 
let elvégzése után. 








[daN [ nincs kávé] a [rincs kóla] 
e -TT 
[van kávé] 
HE [vankóa] 
Kávé betötésea "V/  Vízbetöltésea őV Pohár őV Kólás doboz NY 


kh SEbe W va tartályba — JN ehozatala ./ ke lehozatala / 


. Szűrő behelyezése a 99 
gépbe 











Gép felkapcsdlása 


€ 





Mény kigyullad 











fény kidszik 


V 
Kávé Hal elfogyasztása v-N 


8.2. ábra. Egy aktivitási diagram 








Az első tevékenység két irányban ágazhat szét, ami logikai elágazás: A 
személy italt keres. Ha nem kávét akar, akkor a kóla után néz. Ekkor a 
folyamatban egy olyan döntési helyzet áll elő, amit egy tombusz szimboli- 
zál: van kóla, vagy nincs kóla. Ha van, akkor a következő tevékenység a 
doboz kinyerése, majd tattalmának elfogyasztása. Ha nincs, akkor a folya- 
mat véget ér. A végső, kilépési pontot egy telt kör jelzi, ami egy külső kör- 
tel van keretezve. A diagram kezdő pontja egy sima telt kör. 

A kávé irányában indulva egy fontos szimbólum található, az ún. 
szinkronizációs vonal, ami egy kivastagított vízszintes szakasz. Ez a vonal 
arta szolgál, hogy megszabja azt az időpontot, amikor a belőle kiágazó 
események egyáltalán elindulhatnak. Az ábrán három ilyen esemény indul- 
hat el az első vonal után: Kávé betöltése a szűrőbe, Víz betöltése a tartályba, Po- 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 142 b 


Az UML Nyelv használata Aktivitási diagramok 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 1484b 


bár lehozatala. Ez a hátom tevékenység egymással párhuzamosan folyhat le, 
ahol a sortendjük tetszőleges lehet. Mindegy, hogy melyikük megy végbe 
először, másodszor, vagy harmadszor, de át is fedhetik egymást, vagyis 
egyidejűleg is végbemehetnek. 

Az aktivitási diagram tehát lehetőséget ad arra, hogy megválasszuk a 
tevékenységek végrehajtásának sorrendjét, mármint egy szinkronizált cso- 
porton belül. A diagram egy lényegi sorrendiséget állít fel, amit követni 
kell, nem pedig egy lebontott, részletesen meghatározott sortendiséget. Ez 
fontos különbség a folyamatábra és az aktivitási diagram között. A szoft- 
vettervezésben használt folyamatábrák a szigorúan szekvenciális folyama- 
tok leírására szolgálnak, míg az aktivitási diagram a párhuzamos folyama- 
tokat is tudja kezelni. 

Ez a lehetőség jól kihasználható az üzleti folyamatok modellezésénél. 
Az ilyen folyamatokban igen gyakran alkalmazható a párhuzamos végte- 
hajtás, ami hatékonyabbá teszi a modellezést. Az aktivitási diagram hasz- 
nálata megengedi a tervezőnek, hogy éljen a páthuzamosítás lehetőségével, 
ami javítani tud az üzleti folyamatokon. 

Az aktivitási diagramok igen hasznosak lehetnek az ún. konkurrens brog- 
ramok esetében, ahol különböző szálakon futnak az események. Ezeket a 
szálakat grafikusan tudjuk ábrázolni, és meg tudjuk adni, hogy mikor kell 
őket szinkronizálni, egybehangolni. Amikor ugyanis párhuzamos működés 
áll fenn, mindig szükség van a szinkronizálásra. 

Az adott példában: Addig nem lehet felkapcsolni a kávéfőzőt, amíg 
nem tettük bele a szűrőt, és nem töltöttük bele a vizet a tartályba. Ezért 
van az, hogy a két tevékenység egy szinkronizációs vonalon találkozik. A 
vonal itt azt jelenti, hogy csak akkor léphet fel a kijövő esemény a vonal 
után, ha már mind a két bejövő esemény lezajlott. 

Egy újabb szinktonizáció: A kávé meg kell legyen főzve, és a poharak 
is rendelkezésre kell hogy álljanak, mielőtt kiöntenénk a kávét. 

A másik esetben, amikor is a kóla irányában indulunk el, egy döntési 
elágazás szerepel. Itt az egyik eset az, amikor a Kólás doboz lehozatala tevé- 
kenység megy végbe, a másik eset pedig az, amikor nincs kóla. Az aktivitá- 
si diagramban egymásba ágyazott döntések is meg vannak engedve, tetsző- 
leges számban és mélységben. 

Az ltal elfogyasztása tevékenység két bemenő nyíllal rendelkezik, ami 
azt jelenti, hogy bármelyik nyíl esetén végre lesz hajtva. Ez tehát 
, VAGY" logikai kapcsolatot fejez ki ebben az esetben. Ugyanilyen étte- 
lemben a szinktonizációs vonal pedig , ÉS? kapcsolatot fejez ki. A kime- 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 1484b 


Az UML Nyelv használata Aktivitási diagramok 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 14b 


nő esemény csak akkor történhet meg, ha mindegyik bemenő esemény 
megtöttént mát. 

Implementációs megközelítésben a 8.2. ábra egy metódust ír le, még- 
pedig a Person (Személy) típusra vonatkozóan. Az aktivitási diagramok al- 
kalmasak atra, hogy tetszőleges bonyolultságú metódusokat írjunk le ve- 
lük. Ugyanakkor jól lehet őket használni use case-ek tevékenységi folyama- 
tainak megjelenítésére is, amivel a következő alpontban foglalkozunk. 


8.2. Felbontási hierarchia 


Az aktivitási diagramok több lehetséges működési felbontást képviselhet- 
nek, amelyek hieratchikus kapcsolatban vannak egymással. A felbontások 
fentről lefelé haladva fejtendők ki, az általános működési folyamat (a leg- 
felsőbb szint) leírásától kezdve, és egészen a konkrét megvalósításig (legal- 
só szint) jutva el. 


[21 











b a fi 
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8.3. ábra. Egy általános aktivitási diagram 
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Egy általános aktivitási diagramot tüntet fel a 8.3. ábra, amelyen az egyes 
döntéseket és tevékenységeket betűkkel különböztettük meg. A hierarchiát 
követő felfogásban a 8.3. ábra tevékenységei például lehetnek bizonyos 
banki tranzakciók (betétszámla nyitása, pénz betétele/ kivétele, hitel folyó- 
sítása stb.), míg finomabb felbontásban mindegyik tevékenység például 
egy Java-program műveletének felelhet meg. 

Az ábrán látható (1) szinkronizációs vonaltól három párhuzamos fo- 
lyamat indul el, míg a (2) vonal a folyamatok szinkronizált befejezését 
eredményezi. 


8.3. Aktivitási diagramok use case-ekhez 


Példaként az Order (megrendelés) feldolgozására vonatkozó aktivitási diag- 
tamot vesszük. Ez egy átruházta vonatkozik, ahol a megrendelési folyamat 
a következő lépésekből áll: 

Megrendelési lista átvétele, — raktárkészlet ellenőrzése, — szükség ese- 
tén raktári utánrendelés, — fizetési feltételek ellenőrzése, — megrendelés 
(leszállítás) teljesítése vagy elutasítása. 


e —- 


( Receive 
XN. Order / 
"[ foreach lineitemon order ] 


/ Cancel 9 / Authorize d) / Check Yv 
A ) ) 
A Order  f fajled j Payment / X Jine Item 


[instock] 


[ needto reorder ] 

c Reorder 9 
KV § Item , 
[ stock assigned to all line items and payment authorized ] 


/ Dispatch 9 
XN. Order / 


8.4. ábra. Egy megrendelés fogadása 
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A diagram a 8.4. ábrán látható. Ezen a t jel a megszokott többszörözést 
jelképezi. Annyiszor értendő a vele megjelölt tétel, ahányszor a helyzet azt 
megkívánja. Esetünkben ez a megrendelt árutételek darabszáma. Itt azon- 
nal látható, hogy a legfelső szinkronizációs vonalból ezáltal annyi párhu- 
zamos tevékenység jön ki, amennyi különböző fajta átutételt tartalmaz a 
megrendelés. 

A többszötösen bejövő esemény többszötösen is érvényesülhet egy 
szinkronizációs vonalnál. A példában a Dispatch Order (megrendelés teljesí- 
tése) tevékenység előtti vonalon minden olyan alkalommal ellenőrződik a 
kimenő esemény teljesíthetősége, amikor arra bemenő esemény étkezik. A 
kimeneti teljesítés itt akkor történik meg, ha már mindegyik megrendelt 
árutételt a kért példányszámban egyszette le tudja szállítani az áruház. Az 
aktivitási diagramon a zárójeles magyarázatok teszik ezt egyértelművé. 

Egy aktivitási diagramnak akkor van csak határozott végpontja, ha az 
elindított események lefutása után ott tud véget érni a folyamat. A 8.4. 
ábrán nem szetepel ilyen végpont. 


Receive 
Suppl 


Choose Outstanding 
Order Iltems 





"[ for each chosen order item ] 


Assign Goods ) 
to Order 





PERE V ZGRRBA 


[ stock assigned to all line items and payment authorized ] [ allloutstanding order items filled ] 





,/ Dispatch Order et Remainder 99 
e A toStock / 


8.5. ábra. A beérkező árupótlás fogadása 
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A diagramon ugyanakkor van egy zsákutca is: ez a Reorder [fem (árutétel 
újrarendelése) tevékenység. Ennek végrehajtása után ugyanis semmi több 
nem történik. Egy másik hiányosság is felfedezhető: Mi legyen akkor, ha a 
Cbeck Line [fem (árutétel ellenőrzése) tevékenységnél nem találjuk a raktá- 
ton a keresett tételt? Akkor ez a szál is véget ér itt. Ennek viszont az lenne 
a következménye, hogy a hiányzó tételt nem tudják elküldeni a megrende- 
lőnek. Ahhoz, hogy a megrendelést teljesíteni lehessen, atta van szükség, 
hogy a taktátkészletet előbb feltöltsék a hiányzó áruval. Ez egy külön use 
case beiktatását teszi szükségessé, aminek a tevékenységei eddig nem vol- 
tak definiálva. 


e — PecereOrder 5 
[E 


7 Receive , 
Suppl 














"[ for each ling item on order ] 0 Outstanding 
Order Items / 
Authorize 
s. DÖ tstá) "[ for each chosen order item ] 
[ failed 
[in stock] 
/ Cancel Order Kesirt FESEMEGYEB 
to Order 
NN... Order e 
[ succeeded] 


[ need to reorder ] 


( Reorder Item ) 


[ all outstanding order items filled ] 





[ stock assigned to all line items and payment authorized ] 
V 


Dispatch Order Add Remainder 
sal to Stock 


8.6. ábra. A megrendelés és az árupótlás fogadása 
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Az új use case ellenőtzi a feltöltött készletet a nem teljesített megrendelé- 
sek szempontjából, és intézkedik a lehetséges teljesítésekről. Az ennek 
megfelelő aktivitási diagtam a 8.5. ábrán látható. Ez azt mutatja be, hogy a 
megrendelés addig várakozik, amíg az összes hiányzó tétel be nem érkezett 
a taktárba. 

A 8.6. ábrán az előző két diagram egyesítése szerepel. Ezen jól követ- 
hetjük, hogy miként befolyásolják az egyik use case tevékenységei a mási- 
kéit. Az is látható, hogy nem csak egy kezdőpont van, ami kellőképpen 
tüktözi az üzleti világra jellemző helyzetet, amikor is több külső eseményre 
kell reagálni. 

Általánosan is megállapítható, hogy igen hasznos dolog az egymással 
kapcsolatban álló use case-ekhez úgy szerkeszteni aktivitási diagramot, 
hogy az a use case-ek egyesített működését jelenítse meg. 


8.4. Úszópályák 

Az aktivitási dijiagramok bemutatják az egymást követő történéseket, de azt 
nem fejezik ki, hogy a történések kitől erednek. Nem tükrözik, hogy me- 
lyik részleg vagy melyik személy felelős az egyes tevékenységekért. Prog- 
tamozási szempontból ez úgy éttelmezhető, hogy a diagram nem hordoz 
információt atta nézve, hogy a tevékenységek melyik osztályhoz tattoznak. 
Meg lehetne tenni azt, hogy mindegyik tevékenység mellé odaírnánk, hogy 
melyik osztályhoz vagy személyhez rendelhető, de ez nem nyújtana annyi 
információt, mint az ixterakciós diagramok Ezek, mint tudjuk, az objektu- 
mok közötti kommunikációt mutatják be (Id. az 5. fejezetet). 

Ezen az információhiányon próbál segíteni az ún. úszóbályás (swimlane) 
eltendezés, mégpedig a következő módon: 

Az aktivitási diagramot függőleges zónákba rendezzük, ahol az egyes 
zónák (ezek az úszópályák) szaggatott vonallal vannak elválasztva egymás- 
tól. Mindegyik zóna egy meghatátozott programozási osztályhoz van ren- 
delve, vagy mint a 8.7. ábrán levő példában, egy meghatározott áruházi 
részleghez. 

Az úszópályák atra jók, hogy kombinálják az aktivitási diagramok logi- 


2. 


14. . 


okozhat a zónákra osztás. 
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8.7. ábra: Úszópályás aktivitási diagram 


Az aktivitási diagramokat többféleképpen szokták használni a tervezők. 
Van, aki az objektumokból indul ki, és később rendeli hozzájuk a tevé- 
kenységeket. Van, aki először megrajzolja az aktivitási diagramot, ezáltal 
áttekintő képet alkot a működésről, majd ezt követően tendeli a tevékeny- 
ségeket az objektumokhoz. Általános tecept itt nem adható, mind a két 
megközelítés hasznosnak bizonyulhat. Az a fő, hogy a tervezés eredmé- 
nyeként meglegyen a tevékenységek és az osztályok (objektumok) egy- 
máshoz párosítása. 

A feladatok tetmészetéből adódóan az üzleti modellezésben célszerű 
először a tevékenységeket megtervezni, és csak később megadni azt, hogy 
az egyes tevékenységeket melyik objektum lássa el. 


8.5. Egy tevékenység lebontása 


Sokszor étdemes lehet egy adott tevékenységet tovább részletezni, altevé- 
kenységekte bontani. Ez egy részletesebb aktivitási diagramot fog ered- 
ményezni. Egy ilyen lebontást mutat be a 8.8. ábra, ami a megrendelések 
fizetési folyamatára vonatkozik. A lebontott diagramnak mindig csak 
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egyetlen kezdőpontja van. Végpontja, a szükségtől függően tetszőleges 
számú lehet. Az aktuális példában két végpont van: sikerült a hitelkártya- 
lehívás, vagy nem sikerült. Ez a két etedmény lehet majd a tevékenységet 
megvalósító metódus lefutása után visszaküldött információ, amit a hívást 
leadó objektum kap meg. 

A kellően részletezett tevékenységi diagram alkalmas arra is, hogy be- 
lőle már közvetlenül lehessen a ptrogramkódot írni. (Ekkor már a folya- 
matábra elkészítése is szükségtelenné válhat.) Ha egy folyamat logikai ösz- 
szefüggései túlságosan bonyolultak lennének, akkor étdemes lehet igazság- 
táblázatokat is igénybe venni. 


8.6. Használati célok 

Az aktivitási diagramok nagy előnye az, hogy elősegítik a párhuzamos mű- 
ködés tervezését. Nagyon jó eszköznek bizonyulnak arra, hogy munkafo- 
lyamatokat modellezzünk velük, másrészt pedig arra, hogy a többszálú 
programozást segítsék elő. Ugyanakkor komoly hátrányuk az, hogy nem 
lehet velük egyértelmű és világos kapcsolatot teremteni a tevékenységek és 
objektumok között. Emiatt sok fejlesztő nem is él használatukkal. 
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8.8. ábra. Lebontott aktivitási diagram 
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Mindet összevéve, a gyakotlati tapasztalatok alapján azonban biztosan 
kijelenthető, hogy a következő esetekben bizonyulhatnak hasznos fejlesz- 
tési segédeszköznek: 


Egy use case elemzésénél. Ilyenkor nem kell gondot fordítani atta, 
hogy a tevékenységeket objektumokhoz rendeljük, hanem e helyett ar- 
ta étdemes koncentrálnunk, hogy feltérképezzük, milyen tevékenysé- 
gektre van szükség, és ezek milyen összefüggésben vannak egymással. 
Az objektumokat és a bennük levő metódusokat elég lesz később 
megkonsttuálni, amihez elsősotban interakciós diagramokat használ- 
junk fel. 

Több use case-en áthaladó munkafolyamatok vizsgálatánál. Ez külö- 
nösen hasznos lehet akkor, amikor a use case-ek kölcsönhatásban 
vannak egymással. 


Amikor nem étdemes aktivitási diagramot használni: 


Ha azt akarjuk látni, hogyan működnek együtt az objektumok. Erre az 
interakciós diagramok a legjobbak. 

Ha azt akarjuk látni, hogyan viselkedik egy objektum a teljes működési 
idejében. Ilyen célta legalkalmasabb az állapotdiagtam használata. 
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9. Komponensdiagramok és telepítési 
diagramok 


Az UML diagtamok közül a fizikai megvalósítás leírására jellegzetesen két 
diagramot használnak. A tetvezett szoftvertendszer struktúráját, a prog- 
tamkomponensek, állományok kapcsolatát a kozzponensdiagram (component 
diagram) ítja le, a rendszer fizikai felépítését a zelebítési diagram (deployment 
diagram) tögzíti. 

A fizikai megvalósítás modellezésekor a két diagram közül a telepítési 
diagramnak a használata elterjedtebb, mivel a diagramon nemcsak a rend- 
szer hatdver architektúráját írhatjuk le, hanem az egyes hardver elemeken 
ábrázolhatjuk a rendszet egyes komponenseit is. A telepítési diagram önrma- 
gában egy, a rendszer architekturális felépítését összefoglaló technika, ami 
az egyes szoftverkomponensek által igényelt hatdvetetőfortrásokat ítja le. 

A rendszer architektúrájának modellezésére elsőként a komponensdi- 
agtamot mutatjuk be, majd ezután a telepítési diagram szerepét ismettet- 
jük. 


9.1. A komponensdiagram 


A komponensdiagram (component diagram) a komponensekből felépülő szoft- 
vertendszet struktúráját vázolja fel. Segítségével a tendszer szoftver eleme- 
it rendszerezhetjük, csoporttosíthatjuk, valamint az egyes komponenseket 
egymáshoz rendelhetjük, egymásba leképezhetjük. A diagram jól modellezi 
a szoftverkomponensek egymáshoz való viszonyát, kommunikációját. 

A komponensdiagtam fő építőeleme a kozzponens (component). A kom- 
ponens adott modellelemek (osztályok, csomagok) fizikai egysége. Egy 
fizikailag bonthatatlan szoftver egység, amit állomány, például fottáskód, 
szetkesztendő vagy futtatható szoftver elem: lefordított tárgykód, bájtkód, 
futtatható program vagy dinamikus könyvtár modellezésére lehet használ- 
ni. A fejlesztés menete szetint a tervezési munkaszakaszban meghatáro- 
zott tervezési osztályokat, altendszereket implementáljuk, ami nagyobb 
részben a forráskódok előállítását jelenti. Egy komponensben számos 
implementációs osztály valósulhat meg. 

Az UML a komponens jelölésére egy téglalap szimbólumot használ, 
amelynek bal oldalát két kisebb téglalap metszi. A komponens szimbólu- 
mát a 9.1. ábra illusztrálja. 
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9.1. ábra. A komponens UML szimbóluma 


A komponens diagramban lehetőség van a komponens típusát külön je- 
lölni. A különböző komponens típusok megjelenítésére az UML-ben a 
következő sztereotípusok állnak rendelkezésre: 


e — végrehajtható program : C Cexecutablez3 sztereotípus, 

e forráskódot vagy adatot tartalmazó állomány: CCfilez5 szteteotípus, 

e — statikus vagy dinamikus programkönyvtár: CZlibrary:: szteteotípus, 

e — adatbázistábla: CCtablez3 sztereotípus, 

e alapvetően szöveget tattalmazó dokumentum: CZCdocument55 szte- 
teotípus. 


A komponens diagramban a komponensek által használt vagy felkínált 
metódusok egy csoportját az interfészek (interface) jelölik (lásd 9.2. ábra). A 
modellben az interfészeket üres körök szimbolizálják. 

A szoftvetkomponensek közötti kapcsolatot, kommunikációt a függő- 
ségi viszonnyal írjuk le. A függőségi viszonnyal jól tudjuk modellezni, 
hogy mely komponens melyiknek szolgáltat valamilyen információt, eljá- 
rást stb. A modellben a komponensek közötti függőségi kapcsolatot szag- 
gatott nyíllal prezentáljuk. Komponensek közötti kommunikációt a 9.2. 
ábra komponens diagramja szemlélteti. 


component [ carponent 2 
e- 
I interface lw 
























































9.2. ábra. Komponensdiagram interfésszel 


A komponens szintű modell-tetv a tervezési munkaszakasz végére áll elő. 
A tervezés leírásai szerint meghatározott szoftverkomponenseket az imp- 
lementáció munkaszakaszban fejlesztjük ki. Ahogy már a bevezetőben is 
elhangzott, a komponens diagram sok esetben a telepítési diagrammal 
együtt, azzal összehangolva készül. A gyakorlatban több olyan fejlesztési 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 153 b 


Az UML Nyelv használata Komponensdiagramok és telepítési diagramok 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 154 b 


projekt zajlik, ahol a rendszet hardver architektúrája eleve adott, tögzített 
a megbízó aktuális infrasttukturális környezete miatt. A rendelkezésre álló 
hatdvet infrastruktúra eredményeképpen ilyenkor a komponens modell- 
tetv elkészítése a követelményspecifikáció és elemzési munkaszakaszokra 
tolódhat előre. 


9.2. A telepítési diagram összetétele 


A telepítési diagram (deployment diagram) egy teljes informatikai tendszer 
szoftvet és hardver komponenseit mutatja be, a köztük levő információs 
kapcsolatok, összefüggések feltüntetésével. 

A diagram minden egyes csozópontja (node) valamilyen számítási feldol- 
gozási egységet képvisel, egy szoftvert vagy egy hatdver elemet. A hardvert 
lehet egy kisebb egység, de lehet egy teljes számítógép is. 

A 9.3. ábra egy olyan kórházi rendszer hardver-felépítését mutatja be, 
amely májfunkciók, ill. cukotbetegség vizsgálatára szolgál. A rendszer egy 
személyi számítógépet (PC-t) és két szervert tattalmaz. 

A kótházi rendszer telepítési diagramja a 9.4. ábrán látható. Ezen a di- 
agrtamon a személyi számítógép egy UNIX szerverhez van kötve, a 
TCP/IP hálózati protokoll (kommunikációs interfész) felhasználásával. A 
csomópontok közötti összeköttetések az információcsere, kommunikáció 
útvonalait ábrázolják. 

A szoftvet komponensek azokon a hardver egységeken vannak feltün- 
tetve, ahol végrehajtásra kerülnek, ahol a kódjuk lefut. Fowletnél ezek a 
szoftvert komponensek pontosan megfelelnek a csomagdiagramon ábrá- 
zolt csomagoknak. Vagyis: egy komponens az egy csomag. 

A komponensek közötti függőség ugyanaz kell legyen, mint a csoma- 
gok között meglevő függőség. Ezek a függőségek itt azt mutatják, hogy az 
egyes komponensek hogyan kommunikálnak egymással. Tehát: itt a füg- 
gőség egybeesik a kommunikációval. 

A példában a Liver Unit UI (a májfunkció egység felhasználói interfé- 
sze) függőségben van a Liver Unit Ctient Facade-dal (májfunkció egység 
beteg felé mutatott felülete), mivel az metódusokat hív meg a Facade-ban. 
Bár a kommunikáció itt kétitányú, abban az értelemben, hogy a Facade 
adatokat küld vissza, a Facade nincs tudatában annak, hogy kitől kapta a 
hívást, s így nem áll függőségben a Liver Unzz UI-jal. 

Ha viszont a két helyen előforduló HeaZb Care Domain nevű (egész- 
ségügyi ellátás domén) nevű komponenst tekintjük, mind a kettő tudja, 
hogy egy másik Healtb Care Domain komponenst szólít meg. Ezért a köz- 
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tük levő kommunikáció kétirányú lesz, s így akommunikációs függőség is 
kétirányú. 

Az interfészeket kis karikák teprezentálják. Egy komponensnek egynél 
több interfésze is lehet, amiből látható, hogy melyik komponens melyik 
interfészén keresztül kommunikál. A 9.4. ábrán a Windous PC-nek két 
komponense van: az UI és a Facade. A Facade progtam a szerveren futó 
alkalmazást annak interfészén keresztül tudja elétni. A szetveten fut még 
egy elkülönített konfigurációs komponens, amely két objektumot tattal- 
maz. A szetvet alkalmazási programja kommunikál a saját Health Care 
Domain komponensével, ahol ez a komponens még kommunikálhat több 
másik Healtb Care Domain komponenssel a hálózatban. (A példában csak 
egy másik ilyen szerepel.) 

A Health Care Domain komponensek használata rejtve van a szerveren 
futó alkalmazás előtt. Mindegyik HeaZb Care Domain komponens egy loká- 
lis adatbázissal tendelkezik, az Object Database-zel (objektum-adatbázis). 


9.3. Felhasználási célok 


A gyakotlatban az ilyen diagramokat viszonylag keveset használják. Leg- 
alábbis a szabványos formájában nem, csak egyéni skiccek formájában. 
Vátható azonban, hogy nőni fog a telepítési diagramok jelentősége és fel- 
használási köre, az ún. elosztott hálózati rendszerek terjedésével. Ezek a tend- 
szerek egyre bonyolultabb hardvet-szoftver kommunikációs megoldásokat 
hotdoznak, amihez a telepítési diagramok jó áttekintést tudnak nyújtani. 


Diabetes Unit 
Server 


ra 


Liver Unit Server 














9.3. ábra. Egy kótházi tendszer hatdver elemei 
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9.4. ábra. A kórházi rendszer telepítési diagramja 
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10. Egy UML-modell összefüggősége 
és teljessége 


10.1. A modellezés általános problémái 


Az UML-diagtamok kifejezőképessége és egyszerű használata azt eredmé- 
nyezte, hogy viszonylag könnyen lehet szoftvetmodelleket felépíteni ezek- 
kel az eszközökkel. Ugyanakkor azonban mindez azzal is jár, hogy egy így 
előállított modell nem lesz összefüggő (konzisztens), vagy nem lesz teljes, 
vagy más egyéb hibákat is tartalmazhat. 

A gyakotlatban megépített modellek néhány tipikus hibáját az alábbi- 
akban soroljuk fel: 


1. Az öröklődési kapcsolatokban ciklusok léteznek, vagyis körkörös 
öröklődés alakul ki. 

2. Bizonyos attribútum egyaránt definiálva van az osztályban és az ősosz- 
tályban is. 

3. Egy művelet (metódus) kétszer van definiálva ugyanabban az osztály- 
ban, ugyanazokkal a bemeneti patamétettípusokkal, viszont különböző 
kimeneti etedménytípusokkal. 

4. Egy interfészművelet nincs implementálva egy konkrét alosztályban. 

5. Egy művelet (metódus) kotlátozottabb láthatósággal van definiálva egy 
leszármaztatott osztályban, mint egy ősosztályban. 

6. Egy interfész úgy van definiálva, mint egy osztály alosztálya. 

7. Az állapotdiagtam egy állapota nem érhető el, mett csak kivezető át- 
menetei vannak, amikor az nem kezdőállapot. 

8. Egy állapotcsopott elemei zárt ciklust alkotnak, miután nincs belőlük 
kiágazás. Ezáltal ha valahonnan belépés tötténik a ciklusba, onnan már 
nem lehet egy külső állapotot elérni. 

9. Egy osztály kardinalitása 9-nek van definiálva, míg a hozzá tartozó 
alosztály katdinalitása g-nak, ahol g - 2. 


Az ilyen jellegű hibák kijavítását minél előbb kell megtenni, annak érdeké- 
ben, hogy minél kevesebb fejlesztési veszteség keletkezzék az étvénytelen, 
téves modellek következtében. A hibák feltárása érdekében atra van szük- 
ség, hogy a tetvezők menet közben rendszeresen átvizsgálják az előállított 
modellegységeket, külön-külön is önmagukban, másrészt pedig azok egy- 
máshoz való viszonyát és kölcsönhatását is ellenőrizzék. 





A dokumentum használata ] Tartalomjegyzék ] Felhasznált irodalom Vissza 4 157 b 


Az UML Nyelv használata Egy UML-modell összefüggősége és teljessége 





A dokumentum használata ] Tartalomjegyzék I Felhasznált irodalom Vissza 4 158 b 


A minőség javítása és a modell szükséges átalakítása érdekében többek 
között az alábbiakról érdemes meggyőződni: 


1. Hogy az asszociációknál korrekt számosságot (multiplicitást) alkalmaz- 
tunk. Előfordulhat például, hogy a megadott felső érték kisebb, mint 
amennyire szükség lenne egyes szituációkban. 

2. Hogy az attribútumok és az asszociációk végénél korrekt minősítő 
előírást (gyaljfier) alkalmaztunk. 

3. Hogy az összes olyan esetet felismertük, amelyben egy asszociáció 
végét sortendezni kellett. 

4. Hogy az összes öröklődési esetet számba vettük és leírtuk a modell- 
ben. 

5. Hogy kottekt és informatív típusokat tendeltünk mindegyik attribú- 
tumhoz. Például egy x koordináta típusát a tattományával jelöljük ki, 
vagyis mondjuk 7..15-nek adjuk meg, ahelyett hogy egyszerűen csak [7- 
tegernek deklarálnánk. 

6. Hogy megfelelő állapotokat definiáltunk, amelyek pontosan tükrözik a 
működési módokat és azokat a fázisokat, amelyekbe a rendszer beleke- 
rülhet. Bármely két különböző állapot esetében a rendszernek eltérő 
viselkedést kell mutatnia, máskülönben a két állapot valószínűleg ösz- 
szevonható lesz. 


10.2. Az összefüggőség (konzisztencia) 

Egy UML-modell összefziggő (konzisztens), ha létezik hozzá egy bizonyos 
lehetséges működőképes implementáció. Egy inkonzisztens specifikáció 
azzal ját, hogy nem lehet belőle olyan szoftvett fejleszteni, ami működő- 
képes lenne. Ha például egy C osztályban úgy definiálnánk három egész- 
számú attribútumot (x, y és z) a hozzájuk tattozó megkötésekkel, hogy 


x gy, 
0$Sycaz, 
x—y:zt1, 


akkor nem létezhetne lehetséges megvalósítás a C-re. 

Egy másik már , kifinomultabb"? hibát a 10.1. ábrán látható modellben 
mutatunk be. Az a.f halmazok mindegyike 3-as méretű, és B-nek egy par- 
tícióját alkotja. Az indexelésük A elemei által történik, vagyis B mindegyik 
eleme pontosan egy a.f-ben van benne. Ezért 


B.size — 3 § (A.size), 
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és hasonlóképpen 
A.size — 5  (B.size). 


A két összefüggés csak akkor teljesülhet egyszerre, ha A is és B is üresek, 
vagyis egyik osztálynak sem létezik példánya. 











1 f 
A g 3 B 
5 1 

















10.1. ábra. Egy üres UML-modell 


Az ilyen jellegű konzisztenciaproblémák úgy kerülhetők el, ha megkövetel- 
jük, hogy a specifikáció tartalmazzon konkrét beállítást az attribútumok és 
az asszociációk mindegyik kezdőértékére. A másik lehetőség az, hogy jól 
definiált és dokumentált default-értéket használjunk akkor, ha nem állí- 
tunk be konkrét kezdőéttéket. A fejlesztőnek ilyenkor mindig ellenőriznie 
kell, hogy ezek a kezdőértékek kielégítik a modell összes megkötését. 

Az első fenti példában az egész változók 0-val való default- 
inicializálása nem fogja kielégíteni a megkötéseket, de más egyéb beállítás 
sem elégítené ki, ezért a modell elvetendő vagy módosítandó lesz. 

A második példában az A mindegyik új eleméhez három létező B- 
elemre van szükség ahhoz, hogy az f-et inicializáljuk. Viszont hogy ezek a 
B-elemek létezzenek, az szükséges, hogy már 15 létező A-elemünk legyen. 
Ezért lehetetlen az első A-objektumot léttehozni. 

Az előbbi példákban adatok közötti inkonzisztencia állt fenn. Ugyan- 
akkor lehetséges az is, hogy egy osztály művelete és adata között lép fel 
inkonzisztencia. Egy C osztály op művelete inkonzisztens, ha az op úgy 
tudja módosítani a C egy adatát, hogy megsétti az adat deklarált típusát, 
vagy pedig megszegi a C valamelyik megkötését, ami adatta vonatkozik. 

Például, ha a C osztály az 


xx : 1..139 
formában deklatált attribútummal rendelkezik, akkor az 


incx ( ) 
post : x — xí(pre 11 


művelet megsértheti az x típuskotlátozását. 
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Ha egy műveletet állapotdiagrammal ítunk le, akkor mindegyik állapot- 
átmenetnél arra kell ügyelnünk, hogy az csak akkor következhessék be, ha 
semmilyen megkötést nem sért meg. 

Az állapotdiagramokban is el kell kerülni az inkonzisztens akciókat 
vagy állapotváltozásokat. Ha például két átmenet is bekövetkezhet egy 
esemény hatására, akkor ezek következményei és célállapotai egymással 
konzisztensek kell hogy legyenek. 


10.3. A teljesség 


Egy UML tetvezési modellt /e/esne£ nevezünk, ha az általa leítt szoftvet- 
tendszer állapotai és viselkedési módjai mindegyik lehetséges működési 
esetre és feltételre specifikálva lettek. Egy osztály esetében ez a definíció a 
következő szabályban fogalmazható meg: 

A teljesség hiánya és az inkonzisztencia egymással kapcsolatos prob- 
lémák. Egy művelet inkonzisztens lehet, ha beállít egy azz7 attribútumérté- 
ket, de nem állítja be az az72 attribútumot akkor, amikor ezekre egy meg- 
kötés vonatkozik, ami összekapcsolja a két értéket. 

Ezen az alapon bizonyos teljességi hiányt fel lehet fedni azáltal, hogy a 
konzisztenciát ellenőrizzük. Egy másik teljességhiány magukban a megkö- 
tésekben is felléphet. Például, ha egy osztálynak van két integer attribútu- 
ma, atti és att2, egy Boole-attribútuma, azz3, továbbá egy olyan egyedül 
álló megkötése, hogy 


attl 5 att2 5. att3 — true, 
akkor felmerül a kérdés, hogy mi lesz az att3 értéke abban az esetben, ha 
atti S att2. 


A specifikáció teljességére vonatkozó hasznos ellenőrzés az, ha minden 
egyes A S B típusú megkötést tesztelünk abból a szempontból, hogy 
specifikálva vannak-e azok az esetek, amikor az A logikai értéke , false" 
lesz. Ha ez hiányzik valahol, akkor azt kell ellenőrizni, hogy valóban szük- 
séges-e a specifikálás. 

A teljesség hiányára utal az is, ha egy attribútum nem fordul elő egyik 
megkötésben sem. 

A teljesség érvényesülése megköveteli, hogy az állapotdiagram egy 
adott állapotát tekintve, az abból kiinduló átmenetek mindegyikére telje- 
süljön a következő kritérium: egy átmenethez tattozó logikai feltételek 
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együttes VAGY kapcsolata , ttue? értéket adjon. Ez a ktitérium ugyanis 
kizárja annak lehetőségét, hogy az átmenetet előidéző esemény hatására 
nem következik be átmenet az új állapotba. 

Mindezekhez kiegészítésül még két szabályt adunk meg: 


1. Egy osztály művelete (metódusa) teljes, ha annak hatása definiálva van 
minden egyes lehetséges állapotra, amely kielégíti az osztály összes 
működési feltételeit. 

2. Egy állapotdiagram teljes, ha létezik legalább egy kezdőállapota és leg- 
alább egy végállapota, továbbá a működtetés során mindegyik állapot 
elérhető benne. 


10.4. Megállapítások 


A konzisztencia és teljesség szempontjából a következő megállapítások 
tehetők: 


e Jelenleg nem áll rendelkezésre olyan módszer, ill. a módszert megvaló- 
sító számítógépes eszköz, ami egy szoftvertetv UML-diagtamjai közöt- 
ti összhang bizonyítására, ill. cáfolására lenne alkalmas. 

e Ugyanígy nincs megoldva még a teljesség bizonyításának vagy cáfolá- 
sának feladata sem. 

e A szoftvettechnológia jelenlegi fejlettségi állapotában az UML nyelv és 
a hozzá kapcsolódó diagramok atta szolgálnak, hogy egy szoftvettervet 
több lehetséges és fontos aspektusból tudjunk megjeleníteni és ele- 
mezni, azzal a céllal, hogy minél nagyobb biztonsággal lehessen a 
szoftvett megvalósítani. 

e A wszoftvettervhez az UML-leírások kézi, emberi úton tötténő előállítá- 
sára van szükség. Ezeknek a leírásoknak az összhangját és teljességét 
szintén emberi úton történő összevetés és elemzés tudja csak megte- 
temteni. 


Az automatizált konzisztencia-ellenőtzés és teljességellenőrzés még szá- 
mos kutatási és fejlesztési feladat megoldását követeli meg. Ugyanakkor 
azonban nem vátható, hogy átfogó, abszolút és egzakt megoldásokat le- 
hessen kidolgozni ezen a tetületen. Ez azt jelenti, hogy a tervezésben az 
emberi közreműködés mindig elkerülhetetlen lesz. A számítógépes sze- 
tepvállalás csupán a munkaterhek csökkentésében és a tetvek megbízható- 
ságának fokozásában fog étvényesülni. 
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